Server Fault is a question and answer site for system and network administrators. 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

I am re-thinking our server's permission and group strategy. So I was trying to check what permissions was needed with the current setup for Apache to access the files.

I changed the permissions of index.php to 200 (only write for user). But Apache still could read this file! I then restarted Apache, which fixed this problem. Was Apache running as root, or was it necessary to reboot it for the permissions to take effect?

share|improve this question

migrated from Nov 19 '09 at 13:14

This question came from our site for professional and enthusiast programmers.

Hmmm... Perhaps explain 'apache was still able to read it'. How did you decide this, by viewing in the browser? If that is the case, your browser might have cached it. I would check the access log to confirm this impression if you haven't already. – Kyle Brandt Nov 19 '09 at 15:37
The last GET of that page before it 404s/crashes is about one minute before. I might or might not have had the time to change permissions, repeatedly refresh the page and then reboot Apache in that time.. Anyway, I will give you the correct answer since led me to possibly the correct answer (and for a good explanation)! :) – Znarkus Nov 19 '09 at 17:07
up vote 3 down vote accepted

With apache, you start it as root, but then apache changes its user right after starting. The following in the apache config files set what user it will run as:

User www-data
Group www-data

It has to start as root in general so it can bind to ports < 1024. So run ps aux as wonble said to see how it was started, and adjust these directives if you want to change which user it is running as.

share|improve this answer
All processes but one was running as www-data, and this one was running as root. And this is still the case btw: "root 21526 0.0 0.1 235420 10968 ? Ss 14:00 0:00 /usr/sbin/apache2 -k start" – Znarkus Nov 19 '09 at 13:51
I think that probably with the prefork model, that the one running as root is just there to launch to processes that respond to requests. – Kyle Brandt Nov 19 '09 at 13:56
Are you running any sort of cache modules? – Kyle Brandt Nov 19 '09 at 14:00
You are probably right. We have memcache installed, but are not using it. – Znarkus Nov 19 '09 at 16:49
I would put more money on it being cached in the browser? Are you sure it was accessed from the access.log? – Kyle Brandt Nov 19 '09 at 16:53

On many linux distribution, apache is running as www-data by default

By it is hard to tell without knowing your distribution

share|improve this answer
My dist is Ubuntu, and yes, it runs as www-data. All processes but one, which seemed to be root (by running ps aux | grep apache). – Znarkus Nov 19 '09 at 13:42

The best way to tell the permissions of a process is with ps aux -- that lists the UID of the processes. Now that you've restarted the process, there's no real way of seeing what was going on, short of having something like BSD process accounting running.

share|improve this answer

Chmod 200 will allow the owner of the file to write, but not read the file.

What you want to do is the following:

Let user "joe" own the files. Let group "www-data" read it. This way - joe can log in and modify/upload files, while apache still can read them (chown joe:www-data folder or file).

Chmod*s should be set to something like 750 (or 740 if you don't want directory listing possible) for folders, and 640 (or 750 if it's a CGI) on files.

I'm advising you to learn how chmod/chown interacts, and how the different permissions apply. Please read the follwing helpful article at Wikipeda: Chmod

share|improve this answer
I intentionally made it 200 so no one would be able to read it ;-). I thought write would make me be able to reverse this, I'm a little scared of chmod 000 tbh.. Just to test it, of course! – Znarkus Nov 19 '09 at 13:46

I stand corrected. The actual reason for apache to have been able to read the file would indicate that it had been running as root. Other explanation would have been that the response had been cached in the browser.

I originally wrote: "I think the apache had a cached copy of the index.php in memory. That's why it seemed it could still read the file inspite of permission change."

share|improve this answer
Unless Apache was running a really nasty, buggy, insecure caching module, I'd hope that this couldn't possibly happen. If this is the default behaviour of any part of standard Apache, it needs fixing. – womble Nov 19 '09 at 13:24
Is Apache really caching scripts? This changes everything..! – Znarkus Nov 19 '09 at 13:46
If you use a PHP opcode cache like APC or eAccelerator then Apache will cache the built PHP, but changing the permissions on the files should cause the cache entry to become invalidated. So as womble says if this is the case then something is very (very) broken... – David Gardner Nov 19 '09 at 13:59
+1 For corrected answer – Znarkus Nov 19 '09 at 16:46
Would really just depend on how it defines when a file would be considered dirty. If the caching module works on time stamps for example, if looks at mtime, but not ctime, then changing the permissions would not dirty the file cache. – Kyle Brandt Nov 19 '09 at 17:02

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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