A Day in the Life of #Apache Setting Up File Permissions on Unix by Rich Bowen, coauthor of Apache Cookbook 05/27/2004

Editor's note: In this latest article in the series based on his conversations on the IRC channel #apache, Rich Bowen covers the hows and whys to setting up file permissions on Unix machines.

#apache is an IRC channel that runs on the irc.freenode.net IRC network. To join this channel, you need to install an IRC client (XChat, MIRC, and bitchx are popular clients) and enter the following commands:

/server
irc.freenode.net
/join #apache

Day Six

Last month we talked briefly about file permissions, mixed in with a bunch of other stuff. And file permissions are, indeed, a pretty major topic of conversation on #apache. And although there's some discussion of this in the Apache documentation itself, it's a little terse, and doesn't have a lot of rationale or explanation. So I hope we can clear that up here a little bit.

The disclaimer is that this article is very Unix-centric. If you're running Apache on Windows, there's a good chance that you'll never experience these problems, nor need to know the solutions. This is because Unix has a much more highly developed sense of file ownership and permissions, and so tends to care more about who owns what files, and who is allowed to do what to what file.

So let's start with a common, and apparently simple, question:

<XyZZy> What is the recommended permissions and user/group setup for DocumentRoot?

Or, perhaps, another really common rendition of this question:

<BigWheels> Should I make all of my HTML files owned by the Apache user?

I think what frustrates people the most about these questions is that there isn't one clear and definitive answer to it. If you could say, all the time, make it owned by uid 15, gid 87, and mode 0644, I think people would be a lot happier about it. Alas, there's more to it than that, and you need to actually understand a little more about what's going on.

Here's fajita's take on the question:

<DrBacchus> fajita: file permissions
<fajita> Apache runs as the user specified in the User directive. Files need to be readable by that user. Directories need to be +x (searchable) by that user. CGI programs need to be runnable (+x) by that user. See User and Group. or ALL directories in the path must have +x

Of course, that still doesn't answer the question, but it at least points us in the right direction. What fajita is trying to do, if I may attribute her with some personality, is to point us in the right direction of thought, and allow us to come to our own solutions. Of course, this doesn't always work.

The most important consideration of file permissions is, of course, security. So "just get it working" is not really the point here. Often people will want the fast solution, without really understanding what the reasoning is, and this causes problems in the long run. So slow down a little bit, and try to get some of the theory.

Apache runs as the user specified in the User, and as the group specified in the Group directive. For most of us, these lines in the configuration file look like this:

User nobody
Group nobody

That user is usually (hopefully) an unprivileged user. But what does that mean? Well, to simplify, it means that the user doesn't own anything, and doesn't have execute permissions to anything, and so can't do anything. There are certainly exceptions, which I'll try to mention as we go along, and there are certainly people who disagree with me, some of whom even have good reasons. But I'm the one writing the article. ;-) So I'll repeat it: the nobody user should not own any files; should not be permitted to write to any files; and should be permitted to execute only those files that it specifically needs to, such as CGI programs.

Likewise, the nobody group, which usually only has one member -- nobody -- should not be permitted to own, or write to, any files.

There's quite a bit of room for flexibility in these requirements, but, too, they still don't answer the question of who is to own the content. Well, that one's easy. The folks who have to modify the content should own it. If you have a team of web developers, put them in a web group, and give the files to that group. If you have one developer, then give the files to that one user. Just make sure that the files are still readable by the nobody user, and that directories are +x by the nobody user.

This last point we covered last month, but I'll restate it so that you don't have to go hunting for that article. Directories need to be executable by the Apache user, so that Apache can get listings of the files in the directory, and display the documents located in that directory.

So, specifics. OK: here's an example of a document directory where there's a group of users that edit content:

% ls -lad /usr/local/apache/htdocs
drwxrwxr-x 7 root web 
  4096 Apr 22 12:30 /usr/local/apache/htdocs
  
% ls -al 
  /usr/local/apache/htdocs/index.html
-rw-rw-r-- 1 webguy web 12 Apr 22 11:21 
  /usr/local/apache/htdocs/index.html

In the case of the directory, it is readable, and executable, by the "other" category of users, so that the Apache user (nobody) can descend into the directory, and read the contents. Note that the r is not strictly required there, in many cases.

In the case of the file, it is readable and writeable by members of the web group, and is owned by one particular member of that group, but the "other" category can only read the file.

Why does it matter if the nobody user can write to files? Very simply, it's to prevent CGI programs (and other dynamic content providers) from modifying files to which they would not otherwise have access. And by extension, any user on your system who is permitted to write CGI programs, or SSI directives, can modify or delete any file on the system that is writeable by the nobody user. That's what you're trying to prevent.

Which leads to the exception to the rule. Occasionally, you want files to be writeable by nobody, specifically so that CGI programs can write to them. In that case, it's probably okay. Although you should probably familiarize yourself with suexec to remove the necessity for that. There's an excellent article on the topic on Apache-Server.com.

Finally, a word about public_html directories. A lot of people are concerned about file permissions there. (For some background on what we're talking about here, you might want to read the public_html tutorial.)

The concern is that if permissions are set such that Apache can read content in the home directory, so can everybody else on the system. So, here's the recommendations that protect you from that fate:

chmod 701 /home/rbowen
chmod 705 
/home/rbowen/public_html
chmod 644 /home/rbowen/public_html/*.html And any other content files in that directory

To further protect yourself, you should put any sensitive confidential files in subdirectories of your home directory, which are in turn mode 700. This should protect all of your email, term papers, financial documents, and music files from the prying eyes of other users on the system.

I know this article is a lot more dense and a lot less light and chatty than some of my previous articles, and I hope you'll forgive me for that. I'll try to be more vapid next month. But I hope that I've given at least some insight into file permissions, and not only how to set them, but why.

See you on #apache.

Check back here next month to see how Rich helps to resolve yet another common Apache dilemma.

Rich Bowen is a member of the Apache Software Foundation, working primarily on the documentation for the Apache Web Server. DrBacchus, Rich's handle on IRC, can be found on the web at www.drbacchus.com/journal.

---

O'Reilly & Associates recently (in November 2003) released Apache Cookbook.

• Sample Chapter 9, "Error Handling," is available free online.

• You can also look at the Table of Contents, the Index, and the full description of the book.

• For more information, or to order the book, click here.

---

Return to the Apache DevCenter.