Summary: SELinux is preventing umount (mount_t) "unlink" to /etc/mtab (etc_t). Detailed Description: SELinux denied access requested by umount. /etc/mtab may be a mislabeled. /etc/mtab default SELinux type is etc_runtime_t, but its current type is etc_t. Changing this file back to the default type, may fix your problem. File contexts can be assigned to a file in the following ways. * Files created in a directory receive the file context of the parent directory by default. * The SELinux policy might override the default label inherited from the parent directory by specifying a process running in context A which creates a file in a directory labeled B will instead create the file with label C. An example of this would be the dhcp client running with the dhclient_t type and creates a file in the directory /etc. This file would normally receive the etc_t type due to parental inheritance but instead the file is labeled with the net_conf_t type because the SELinux policy specifies this. * Users can change the file context on a file using tools such as chcon, or restorecon. This file could have been mislabeled either by user error, or if an normally confined application was run under the wrong domain. However, this might also indicate a bug in SELinux because the file should not have been labeled with this type. If you believe this is a bug, please file a bug report (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) against this package. Allowing Access: You can restore the default system context to this file by executing the restorecon command. restorecon '/etc/mtab', if this file is a directory, you can recursively restore using restorecon -R '/etc/mtab'. Fix Command: restorecon '/etc/mtab' Additional Information: Source Context system_u:system_r:mount_t:s0 Target Context unconfined_u:object_r:etc_t:s0 Target Objects /etc/mtab [ file ] Source umount Source Path /bin/umount Port <Unknown> Host pinot.openconc.com.au Source RPM Packages util-linux-ng-2.14.2-9.fc11 Target RPM Packages setup-2.8.3-1.fc11 Policy RPM selinux-policy-3.6.12-62.fc11 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name restorecon Host Name pinot.openconc.com.au Platform Linux pinot.openconc.com.au 2.6.29.6-213.fc11.x86_64 #1 SMP Tue Jul 7 21:02:57 EDT 2009 x86_64 x86_64 Alert Count 12 First Seen Mon 27 Jul 2009 06:47:38 AM EST Last Seen Mon 27 Jul 2009 07:22:38 AM EST Local ID b9f3ade2-2327-4e06-8f1d-77b5a43b10ac Line Numbers Raw Audit Messages node=pinot.openconc.com.au type=AVC msg=audit(1248643358.170:132): avc: denied { unlink } for pid=10884 comm="umount" name="mtab" dev=dm-4 ino=1404 scontext=system_u:system_r:mount_t:s0 tcontext=unconfined_u:object_r:etc_t:s0 tclass=file node=pinot.openconc.com.au type=SYSCALL msg=audit(1248643358.170:132): arch=c000003e syscall=82 success=no exit=-13 a0=7ff38fc455b7 a1=7ff38fc45586 a2=7ff3912b70a0 a3=7fffffaef6e0 items=0 ppid=2477 pid=10884 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="umount" exe="/bin/umount" subj=system_u:system_r:mount_t:s0 key=(null)
Execute what setroubleshoot suggests: # restorecon /etc/mtab Will fix. But the question is how /etc/mtab got this wrong context.
Yes, restorecon fixed it. > But the question is how /etc/mtab got this wrong context. Sure. All I can say is I installed the latest updated yesterday. Is there a log file that you would like me to attach to show what was updated?
Well something in a post install of an rpm package must have updated the /etc/mtab file. I have a feeling something actually executed mount, or some other tool that updated the /etc/mtab file and left it labeled incorrectly.
Does # rpm -qa --scripts | grep mount show anything?
Yes, vmware executes mount and umount. It does this with some reference to selinux: vmware_exec_selinux "mount -t vmblock none /proc/fs/vmblock/mountPoint" vmware_exec_selinux "umount /proc/fs/vmblock/mountPoint" vmware_exec_selinux "mount -a -t $vmhgfs" vmware_exec_selinux "umount -a -t $vmhgfs" But, how can executing the mount command break the selinux label on a file unless the mount command is faulty?
more info.... here's the vmware_exec_selinux function: vmware_exec_selinux() { local command="$1" # XXX We should probably ask the user at install time what context to use # when we retry commands. unconfined_t is the correct choice for Red Hat. local context="unconfined_t" local retval $command retval=$? if [ $retval -ne 0 -a "`isSELinuxEnabled`" = 'yes' ]; then runcon -t $context -- $command retval=$? fi return $retval } and I guess that explains the problem! The "context" setting is no longer correct.
So....how can the script be improved? Ideally, that function should interrogate the system to find the correct context to run the command. I guess that depends on the command, but do you have any ideas on what to do here? Maybe a ls -lZ <first word of $command>, then grab the context and runcon with that context. Does that sound about right?
I am not sure what this script was trying to do. It they are after the same transition rules that would be happening if the unconfined domain executed the mount command they missed the boat. If they had just contacted me to report the bug I would have told them we need to add a transiton role from rpm_script_t -> mount_exec_t -> mount_t and their bug would be solved. To fix the script they gave, you actually want to execute a shell. Currently they are executing mount as unconfined_t which will end up creating the /etc/mtab as etc_t, where as if a shell script running as unocnfined_t executed mount it would have transitioned to mount_t and created the file as etc_runtime_t. runcon -t unconfined_t -- mount ... This says run the mount command as unconfined_t, which will break runcon -t unconfined_t -- sh -c mount ... Will work closer to what they expected. This would run /bin/bash as unconfined_t which then would execute a file named mount_exec_t as mount_t, which creates the files with the correct context.
Yes they could have just run the commands and fix the context when they were done.
I guess that's why VMWare doesn't support Fedora as a host operating system. It's probably too hard to take account of every variation of every distribution. It will be interesting to see if I get the same problem when I reboot the computer. In which case, I'll have to hack it. I'm not sure when VMWare runs that code, but it's probably to do with startup/shutdown.
Sadly, if they would just work with us, we could get it working without any hacks. That is the way Open Source works. mgrepl, can you add a mount_domtrans(rpm_script_t) to rpm.te
Fixed in selinux-policy-3.6.12-70.fc11
This message is a reminder that Fedora 11 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 11. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '11'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 11's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 11 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping