I'm from a programming background and been thrown into managing a Linux server at work because of an emergency with our reg sys admin. Is it reliable or safe to have our PHP files owned by root yet Apache obviously running on Fedora 8 as apache?

Apache is given rights to read and in minor cases like the uploads directory, write privileges by chmod 777 for that uploads folder.

We are running mod_security but wondered if there was some better practice. I'm alone on this for the next 2-3 weeks while the sys admin is recuperating.


What group owns the PHP files? Your mention of 777 suggests that it's the 'wheel' or 'adm' or some other privileged group, so that the only way Apache can see any file is when that file is world-readable. Or world-writable, in the case of the uploads folder.

That's almost certainly not a good thing -- although the severity would depend on what all you're running on the server (both web-based and otherwise), whether any of the PHP scripts contain plaintext credentials, etc.

If, on the other hand, the files are owned by the gid that Apache runs under, then you're in somewhat better shape. You could in theory do a chmod -R o-rwx on DocumentRoot to remove all "world" privileges, and everything would most likely be nice and safe and your web pages would still work.

But then there's the question of setuid bits. I'm not sure off the top of my head whether a root-owned PHP script with setuid turned on could, in practice, be exploited for malicious purposes, but I wouldn't want one on my web server.

And even if setuid is not a concern, the root-ownership still doesn't smell right to me.

| improve this answer | |
  • Hi Ben, thanks for the feedback. I had to quickly setup the plain Fedora server so I installed php,mysql,etc. as root. It runs as a module with Apache. I guess I am trying to figure out, if Apache (user or grp) own the directories, wouldn't they be writable to a web user since they're there via Apache? Thx again. – miamisoftware Jun 5 '09 at 18:41
  • Perhaps, if (a) the write bit is set on the directories and (b) there are vulnerabilities in the PHP scripts that permit unintended writing to the filesystem. You can cover (a) by setting 550 permissions on the directories (i.e. r-xr-x---), or thereabouts -- and cover (b) by only using secure code! ;-) – Ben Dunlap Jun 6 '09 at 1:17
  • Also I don't think there's anything unusual about installing PHP and so forth as root. You would normally need root privileges to do this, and the install script should have taken care of adjusting permissions on the binaries and config files and so forth. – Ben Dunlap Jun 6 '09 at 1:19

If you are running PHP in such a way as it runs as Apache's user (i.e. "www-data" on debian systems, "nobody" on CentOS+cPanel shared hosts, ...) then the owner of the file doesn't really matter from the PoV of being called via Apache - PHP and therefore the script will always be running as the Apache user not the user that owns the file.

If you run PHP as a module then this is almost certainly the case.

If you have PHP configured to run scripts as the specific user (via suphp, suexec, or similar - you may be doing this if you run PHP via the CGI or FastCGI methods) then having script files owned by a privileged user is a very bad idea.

As for "777" permissions, this should be avoided too especially if you are not the only user on the server. I would instead make sure that the directory is owned by the user Apache will be running PHP as and use "700" (or in a group that this user is also in and use 770). For greater paranoia, if your scripts will always know the filename they want and don't need to read the directory listing, disallow execute permission on the directory too.

Also never have scripts world-writable. Default suPHP setups actually protect you from this a little by refusing to run scrips that with permissions that are world-writable (or in directories that are).

As a general rule, I avoid using less restrictive permissions in development than would be needed in a live, publicly available, environment. This avoids accidentally leaving the perms too permissive when promoting code to live, and avoids introducing bugs where your code assumes more permissive access than it is allowed in the live environment.

| improve this answer | |
  • Thanks David. The setup is via mod_php. I appreciate the insight with the lack of execute meaning lack of directory listing. – miamisoftware Jun 5 '09 at 18:51

777 permissions are usually considered a Bad Idea for PHP scripts. If the files are owned by the root user, you'll likely want them to at least be owned by the apache group so they don't have to be world readable if that's not what you want. This way you could scale back to 770 permissions. (It seems a little odd for the scripts to be owned by root to begin with, too.)

For the future, you might also want set the sticky bit on the directory to ensure that new files added to that directory are automatically chgrp'd to whatever group owns the directory with the following command:

chmod 2775 /path/to/directory

This way, you can (for example) set the group owner of the directories you're serving to apache, and new content that gets added will automatically be in the apache group and thus readable without needing to grant world-readable permissions (assuming an appropriate umask).

| improve this answer | |
  • Thanks for the pointers. Definitely have to lookup sticky bit! – miamisoftware Jun 5 '09 at 18:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.