Fedora Linux

During system startup, your files will be relabeled to default values, except for files labeled with a type listed in /etc/selinux/targeted/contexts/customizable_types . The relabeling operation will typically take a few minutes on a desktop system or small server, and could take much longer on a large server or very old computer.

8.2.1.5. Viewing and interpreting SELinux messages

SELinux policy messages are sent to syslog and usually end up in /var/log/messages . To find them among the other messages, search for the string avc :

# grep avc: /var/log/messages
May 2 16:32:56 laptop3 kernel: audit(1146601976.667:289): avc:
denied { getattr } for pid=23807 comm='httpd' name='public_html' dev=dm-1
ino=192237 scontext=user_u:system_r:httpd_t:s0
tcontext=user_u:object_r:user_home_t:s0 tclass=dir

Here we see that an access request was denied between a subject with an scontext of user_u:system_r:httpd_t:s0 and a tcontext of user_u:object_r:user_home_t:s0 for the tclass dir (a filesystem directory). The additional fields provide a bit more information: the attempted operation was getattr (get attributes), the process ID of the subject was 23807, the command executing was httpd , the directory name was public_html , the storage device was dm-1 , and the inode number was 192237.

The fact that the storage device name starts with dm (which stands for device mapper ) indicates that the directory is stored in a logical volume. You can find the device number from a detailed listing of the device node:

$ ls -l /dev/dm-1
brw-r----- 1 root disk 253, 1 Apr 29 08:57 /dev/dm-1

The output indicates that the device number is 253, 1 . Compare this with the device nodes in /dev/mapper :

$ ls -l /dev/mapper
total 0
crw------- 1 root root 10, 63 Apr 29 08:57 control
brw-rw---- 1 root disk 253, 1 Apr 29 08:57 main-home
brw-rw---- 1 root disk 253, 3 Apr 29 08:57 main-remote
brw-rw---- 1 root disk 253, 0 Apr 29 08:57 main-root
brw-rw---- 1 root disk 253, 4 Apr 29 08:57 main-test
brw-rw---- 1 root disk 253, 2 Apr 29 08:57 main-var

According to this output, /dev/dm-1 corresponds to /dev/mapper/main-home , which refers to the logical volume home within the volume group main . The mount command shows the mount point for this volume:

$ mount
/dev/mapper/main-root on / type ext3 (rw)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
/dev/hdc2 on /boot type ext3 (rw)
tmpfs on /dev/shm type tmpfs (rw)
/dev/mapper/main-home on /home type ext3 (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
automount(pid10695) on /net type autofs (rw,fd=4,pgrp=10695,minproto=2,maxproto=4)

We know that the directory filename is public_html , but we don't know the full pathname of the directory. Passing the mount point and inode number to find will reveal the pathname:

# find /home -xdev - inum 192237
/home/chris/public_html

The -xdev argument limits the search to a single filesystem.

So now we know that httpd (Apache) was unable to access the directory /home/chris/public_html .

The command audit2why will attempt to decode SELinux error messages:

# grep avc: /var/log/messages|audit2why
May 2 16:32:56 laptop3 kernel: audit(1146601976.667:289): avc: denied { getattr } for pid=23807 comm='httpd' name='public_html' dev=dm-1 ino=192237 scontext=user_u:system_r:httpd_t:s0 tcontext=user_u:object_r:user_home_t:s0 tclass=dir
 Was caused by:
  Missing or disabled TE allow rule.
  Allow rules may exist but be disabled by boolean settings; check boolean settings.
  You can see the necessary allow rules by running audit2allow with this audit message as input.

This explanation is not very informative, but it does tell us that there is no type enforcement rule to allow this access, and that may be because of a boolean setting. Viewing the manpage for httpd_selinux gives information about the necessary boolean setting, along with the required context label:

httpd by default is not allowed to access users home directories. If you want to allow access to users home directories you need to set the httpd_enable_homedirs boolean and change the context of the files that you want people to access off the home dir.
 setsebool -P httpd_enable_homedirs 1
 chcon -R -t httpd_sys_content_t ~user/public_html

Issuing the commands given in the manpage fixes the problem. Here I've substituted the actual user's name into the chcon argument:

# setsebool -P httpd_enable_homedirs
# chcon -R -t httpd_sys_content_t ~chris /public_html