4 posts • joined 29 Jun 2007
Every CMS known to man requires a space writeable by the web server / server side scripts. As such, owning all files by another user will only protect *part* of your docroot, and as such all you're really providing is 'security through obscurity'. If you're not using a CMS, then you can further lock down your docroot by making files ( and directories! ) immutable, which is as far as possible a completely secure solution.
Some cron jobs *must* run as the damon user. A specific example: Magento re-index creates a lock file for each index as it works on it, which ends up owned by the user running the process ( assuming they had permission to overwrite it in the first place ). This will prohibit the interactive run of a reindex from the CMS backend as the file can't be recreated by the daemon ( yes there's a million and one ways around this, but I'm making a point! ).
Chroot jails are also provably insecure... if you're this bothered about security, then you need to separate via VMs, or the new lightweight altrnative, docker, which I'm desperately trying to find time to investigate further. All other alternatives lull you into a false sense of security to some level.
I agree 100% on the chmod 777 thing though, anyone who writes this has no concept of *nix file permissions. Any software install instructions containing this requirement prompts me to delete it immediately, and be very circumspect on any other software from the same author.
All you need Is a virtual presence. Website, computer and a decent Internet connection and you're away. No more commute, work your own hours... Well, it's not that simple, but it's an alternative to throw into the mix.
Nobody need know how old you are if you don't want them to.
my link is so unreliable that...
wget -c http://go.microsoft.com/fwlink/?LinkId=104679
off linux to get it. Go figure!
He wants to do this by when: 2004???