Description of problem: A manual unmount of a file system changes the /etc/mtab security context from system_u:object_r:etc_runtime_t to root:object_r:etc_t. Subsequent mount or umount operations are denied access to this file due to the improper labeling. Either this is a bug in the selinux policy (targeted) or the umount application. Version-Release number of selected component (if applicable): selinux-policy-targeted-2.2.23-15 util-linux-2.13-0.20 How reproducible: Steps to Reproduce: 1. observe security context of /etc/mtab (ls -X /etc/mtab) 2. umount a file system 3. note that the security cntext of /etc/mtab has changed 4. mount a file system 5. note the avc error logged to /var/log/messages Actual results: May 5 18:13:48 localhost kernel: audit(1146878028.422:538): avc: denied { write } for pid=3568 comm="mount" name="mtab" dev=dm-2 ino=165903 scontext=system_u:system_r:mount_t:s0 tcontext=root:object_r:etc_t:s0 tclass=file M Expected results: no error Additional info:
By the way, this problem is particularly bad for me as I use autofs. Per automount behavior, file systems are mounted implicitly on demand and unmounted implicitly after a period of disuse. After the first implicit umount, the /etc/mtab file is mislabeled and screws up everything afterward. The problem is really noticeable when shutting down the system and seeing all the syslog messages on the console that come when trying to umount everything.
Fixed in selinux-policy-2.2.34-3.fc5 You might also want to run restorecond service restorecond start