Back in the day DEC support suggested that the cause of random shutdowns could be alpha particles released when opening brown cardboard boxes.
Well at least they brightened our day.
9 publicly visible 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.