Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

it seems that the only way I can get PHP applications to work is through giving each file 0777 permissions. Is this safe for a web server environment?

i.e. Will anyone be able to edit my files?

share|improve this question
up vote 0 down vote accepted

Having daemons, i.e. a web server, run as a non-root user gives you a layer of protection if that particular executable is compromised. (Note that "forking" servers such as apache have one process that runs as root and worker subprocesses that do not. This is needed so that apache can bind to a privileged (<1024) port number.)

If your webserver is apache for example, and it runs as www-data:www-data, someone who finds and then takes advantage of an exploit can only have the same privileges as the www-data user or www-data group. It can also only access files that are owned by www-data user, owned by the www-data group, or world readable/writeable/executable.

Having PHP scripts modifiable (i.e. write permission) by www-data would mean an attacker who got in by way of your HTTP daemon could then replace that script with any code he/she wants. PHP scripts should not need to be modifiable by www-data unless they are badly written or not meant to run in the context of a web server (which is rare).

You may want certain directories modifiable if the application saves data or otherwise uses the filesystem. I usually symlink these off to something off the main filesystem. Even then, for complete security you do not want www-data:www-data to be able to write new files into anything that your HTTP daemon will call PHP from. apache, through the use of .htaccess files and <Directory> stanzas in the config files can be configured to not execute PHP in certain directories - if you want to be really comprehensive about it.

share|improve this answer

Yes. Anyone will be able to edit your files. Thats what the last "7" means.

Without knowing your application, I'm guessing maybe what you want is permission 775 on those files which are supposed to be read/written to through the application, and ensure that the group is set to the apache user. Even so, be aware that if something is compromised on that box, people can probably still read and write those files - there is no simple way around this. (You can manage the problem a number of ways, but none are simple).

share|improve this answer
I'm running nginx, and it appears that it runs through a user called www-data. Should I give the group permissions to that? If so, then why can't I see it in the users list in some places? – Joey Miller Mar 10 '13 at 4:00
Probably, and I don't know what you mean by "If so, then why can't I see it in the users list in some places? ". If the system recognises the user - simplisticly speaking if they have an entry in /etc/passwd and /etc/shadow then the user exists. Yes, www-data is probably the correct user (but I have never looked at nginx) – davidgo Mar 10 '13 at 4:15
The userlist problem is likely something with WinSCP. Sometimes www-data will not display in the group/owner list for files. But yes, assigned permissions and stuff works so thank you! – Joey Miller Mar 10 '13 at 4:22

This has been answered pretty well over at stack.

You need to look in to suexec. It's a pain to setup if you don't know what you're doing, but it can help isolate breaches by letting apache access files as a user.

share|improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .