A file label that has been changed manually may be changed back to the default value during a relabeling (discussed in the next section).
For example, if you have created the /var/samba directory and are using it for Samba group shares, it will need to be labeled with the type samba_share_t :
# chcon -R -t samba_share_t /var/samba
To make that the default context label for /var/samba , edit /etc/selinux/targeted/contexts/files/file_contexts.local to contain this line:
/var/samba(/.*)? system_u:object_r:samba_share_t
The first field contains a regular expression specifying that this entry will match any filename starting with /var/samba . The context label in the second field (which must include the system_u:object_r: portion) configures the default label for files that match the regular expression.
8.2.1.4. Relabeling the system
Some caution is in order: you may end up with a system where many file labels are wrong if you update your SELinux policy, mount your filesystems without SELinux support enabled (perhaps during rescue mode), or go wild with chcon . To relabel your system, you should create the empty file /.autorelabel and then boot the system:
# touch /.autorelabel
# shutdown -r now
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 kerneclass="underline" 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 kerneclass="underline" 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.