Setting up a new directory tree in httpd

With SELinux?, there are a few tricks to setting up a new directory to be handled by the Apache server. But before we get to the tricks, let us first cover the basics which are used across all UN*X releases.
The first step in adding a directory of content to Apache is to create a <Directory> entry in the Apache configuration file. This is a rather simple step, done for everything from your main DocumentRoot?, your icons, and your CGI scripts, and tells the server where to look. So, an entry for serving up a mirror of the Fedora repository stored locally on the disk with the path /mirrors/fedora might look like this:

<Directory "/mirrors/fedora/">
    Options Indexes MultiViews
    AllowOverride None
    Order allow,deny
    Allow from all
</Directory>

The contents of this particular configuration block says that the Apache server is allowed to generate the directory index if the index.html file (or equivilent) is missing, content negotiation can result in multiple views, no other option overrides are permitted, and that anyone can access the directory.
With that complete, the second step is to provide a way to map a URL to the directory. pLike is done for your icons and CGI scripts, you need to add a line like this:

Alias /pub/fedora/linux/ "/mirrors/fedora/"

The final step is to make sure that the permissions on all directories to the destination are allowing search (x) permissions to the server, that the directories containing the content allow read and search (rx) permissions to server, and that the files in content directory are readable. In this example, that would mean that if the files were not owned by the user running the server (apache, www, or something else, depending on your distro/install), we could accomplish this with these commands (or something like them):

# chmod 744 /mirrors
# find /mirrors/fedora -type d -print0   | xargs -0 chmod 755
# find /mirrors/fedora ! -type d -print0 | xargs -0 chmod 644

NOTE: The '#' beginning these lines is the shell prompt, indicating the commands are being executed by the superuser. Running commands as the superuser is normally a ``Bad Idea(TM)'' for security, since you should do as little as possible as superuser. But, since we are working with directories which may not be owned by a non-root user, this is the user which will be used.
At this point, on systems without SELinux?, all is happy and all you need to do is to check your configuration file syntax by executing apachectl configtest, and if all is well, then executing apachectl graceful to restart your server. But SELinux?, with all its beauty (such as making it much more difficult for some cracker to compromise your system), adds a nasty and often forgotten twist. With the manditory access control (MAC) of SELinux?, you must explicitly grant a security context to the Apache server. This is because the Apache httpd daemon is running in a context of reduced permissions, which provide restrictions beyond the familiar file/directory permissions. But, these contexts are hidden, and so we must first know how to see them. To see the security context of the httpd daemon, we can issue the following command, shown with its output:

# ps axZ | grep httpd
root:system_r:httpd_t           27899 ?        Ss     0:00 /usr/sbin/httpd
root:system_r:httpd_t           27901 ?        S      0:00 /usr/sbin/httpd
root:system_r:httpd_t           27902 ?        S      0:00 /usr/sbin/httpd
root:system_r:httpd_t           27903 ?        S      0:00 /usr/sbin/httpd
root:system_r:httpd_t           27904 ?        S      0:00 /usr/sbin/httpd
root:system_r:httpd_t           27905 ?        S      0:00 /usr/sbin/httpd
root:system_r:httpd_t           27906 ?        S      0:00 /usr/sbin/httpd
root:system_r:httpd_t           27907 ?        S      0:00 /usr/sbin/httpd
root:system_r:httpd_t           27908 ?        S      0:00 /usr/sbin/httpd

The security context is the "root:system_r:httpd_t" at the beginning. The full explaination of this is beyond the scope of this entry, and all that is needed is to know that the server runs in an httpd type context.
The next step is the directory tree itself. To see the security context of a directory tree, we might issue the following command and see the resulting output:

# ls -aZ /mirrors
drwxr-xr-x  root    root  root:object_r:root_t             .
drwxr-xr-x  root    root  system_u:object_r:root_t         ..
drwxr-xr-x  cinnion users system_u:object_r:file_t 	   fedora
drwxr-xr-x  root    root  system_u:object_r:file_t         home

In this case, things are not as they need to be, and trying to access the directory in your browser will get you 403 errors. So we must do a few extra steps. First, we must update the security context of the /mirrors/fedora tree itself to have httpd_sys_content_t. We can do this with the following command:

# chcon -R -t httpd_sys_content_t /mirrors/fedora

An even more complete command might be the following:

# chcon -R user_u:object_r:httpd_sys_content_t /mirrors/fedora

However, we are not quite done. These twisty passages are even twistier than they seem at first. Since we are not dealing with a directory straight off of the root directory, we must also grant the httpd daemon a security context through /mirrors. And so, one way of doing this would be to issue the following command (taken from looking at /var/www):

# chcon system_u:object_r:var_t /mirrors

With this done, here we see the final result:

ls -aZ /mirrors
drwxr-xr-x  root    root  system_u:object_r:var_t          .
drwxr-xr-x  root    root  system_u:object_r:root_t         ..
drwxr-xr-x  cinnion users user_u:object_r:httpd_sys_content_t fedora
drwxr-xr-x  root    root  system_u:object_r:file_t         home

---

External References:

Apache HTTP Server Version 2.2 Documentation

Fedora Core 5 SELinux FAQ

Understanding and Customizing the Apache HTTP SELinux Policy (Beta Document)