Hide Forgot
Description of problem: When attaching an external usb-disk, the partitions are mounted, but the information isn't stored in /etc/mtab. Therefore the partitions don't show up when running df and appear as not mounted in the gnome Computer window. When I try to open them in the gnome Computer window there is an error stating "Cannot mount volume". Accessing the volumes by opening /media/disk in nautilus is possible without problems. /var/log/messages shows some audit avc messages
Created attachment 126434 [details] excerpt of /var/log/messages
the problem still exists with selinux-policy-targeted 2.2.25-2.fc5
The problem is caused by incorrect context on /etc/mtab. On a fresh FC5 install, /etc/mtab gets created as "etc_t" instead of "etc_runtime_t", so hald cannot write to it when new volumes get mounted. Restoring the correct context fixes the problem: [mikeb@liffey ~]$ ls -laZ /etc/mtab -rw-r--r-- root root user_u:object_r:etc_t /etc/mtab [mikeb@liffey ~]$ sudo restorecon /etc/mtab [mikeb@liffey ~]$ ls -laZ /etc/mtab -rw-r--r-- root root system_u:object_r:etc_runtime_t /etc/mtab [mikeb@liffey ~]$
Ok, that works to some extent. But as soon as I unmount one of the partitions the wrong context is set again. [root@staschko ~]# ls -laZ /etc/mtab -rw-r--r-- root root user_u:object_r:etc_t /etc/mtab [root@staschko ~]# restorecon /etc/mtab [root@staschko ~]# ls -laZ /etc/mtab -rw-r--r-- root root system_u:object_r:etc_runtime_t /etc/mtab [pluging in the external disk and waiting a few seconds until it's mounted] [root@staschko ~]# df Dateisystem 1K-Blöcke Benutzt Verfügbar Ben% Eingehängt auf /dev/mapper/VolGroup00-LogVol00 77577136 49471752 24101136 68% / /dev/hda2 101105 13858 82026 15% /boot tmpfs 631212 0 631212 0% /dev/shm /dev/sda1 153826820 131015052 14997756 90% /media/musik-bilder /dev/sda3 153834884 144639068 1381400 100% /media/disk [root@staschko ~]# ls -laZ /etc/mtab -rw-r--r-- root root system_u:object_r:etc_runtime_t /etc/mtab [root@staschko ~]# umount /media/musik-bilder/ [root@staschko ~]# ls -laZ /etc/mtab -rw-r--r-- root root user_u:object_r:etc_t /etc/mtab
Could you try out restorecond? chkconfig --add restorecond service restorecond start
To get restorecond I need policycoreutils from rawhide? Is this compatible with FC5?
It is but, you can grab the one in fc5-test which will be released tonight. Rather than updating to the latest tool chain.
No good. Installed policycoreutils-1.30.1-2.fc5 from updates-testing and started restorecond. With restorecond running: [mikeb@liffey ~]$ ls -laZ /etc/mtab -rw-r--r-- root root system_u:object_r:etc_runtime_t /etc/mtab [mikeb@liffey ~]$ sudo umount /media/disk [mikeb@liffey ~]$ ls -laZ /etc/mtab -rw-r--r-- root root user_u:object_r:etc_t /etc/mtab [mikeb@liffey ~]$ ls -laZ /etc/mtab -rw-r--r-- root root user_u:object_r:etc_t /etc/mtab [mikeb@liffey ~]$ ls -laZ /etc/mtab -rw-r--r-- root root user_u:object_r:etc_t /etc/mtab [mikeb@liffey ~]$ I suspect umount is creating a new temporary file in /etc, copying the relevant parts of /etc/mtab into that file, and then renaming the temporary file to mtab. Is restorecond catching this case?
I've tried restorecond from policycoreutils-1.30.1-2.fc5. It resets the file context of /etc/mtab once when I start the service but it doesn't correct it after the drive is unmounted. The service seems to be running. ps axef shows 6360 ? Ss 0:00 /usr/sbin/restorecond TERM=xterm PATH=/sbin:/usr/sbin:/bin:/usr/bin PWD=/ LANG=de_DE.UTF-8 SHLVL=2 _=/usr/sbin/restorecond I'll try it again when a new version of policycoreutils appears in updates-testing. The fact that the volume is shown as not mounted in gnome and the "Cannot mount volume" error message seem to be a different problem as they also exist when I manually restore the context and the volumes are shown in df.
Ok, with policycoreutils-1.30.1-3.fc5 the problem with /etc/mtab is gone, restorecond resets the file context after each umount. The problem that the volume appears as not mounted in gnome still exists.
Are you seeing AVC message?
Just the ones that are in the excerpt of /var/log/messages. Right after the drive is mounted: ... avc: denied { getattr } for pid=2336 comm="hald" name="/" dev=sda1 ... And after double-clicking on the icon in the gnome computer window: ... avc: denied { getattr } for pid=5377 comm="hal-system-stor" name="/" dev=sda1 ... ... avc: denied { getattr } for pid=5377 comm="hal-system-stor" name="/" dev=sda1 ... ... avc: denied { search } for pid=5381 comm="touch" name="/" dev=sda1 ... ... avc: denied { search } for pid=5381 comm="touch" name="/" dev=sda1 ... ... avc: denied { getattr } for pid=5377 comm="hal-system-stor" name="/" dev=sda1 ...
Does the external drive contain an ext3 filesystem? I got rid of the avc messages at mount time by chcon'ing the root directory of the ext3 filesystem to system_u:object_r:removable_t, which hald can read. For filesystems without xattr support, the kernel should probably default to removable_t instead of file_t, which hald cannot read.
Yes, that did the trick. It works without problems now. Thank you both.
(In reply to comment #13) > Does the external drive contain an ext3 filesystem? I got rid of the avc > messages at mount time by chcon'ing the root directory of the ext3 filesystem to > system_u:object_r:removable_t, which hald can read. For filesystems without > xattr support, the kernel should probably default to removable_t instead of > file_t, which hald cannot read. This worked for me also!!! I was pulling my hair out! My backup USB drive was being mounted by HAL but I was unable to easily umount it! Thanks!
I had exactly the same problems. I have an additional IDE-HD partition and an external USB HD, both with ext3 filesystem. I changed the context of the root directories of both filesystems to system_u:object_r:removable_t and now it works. A question: My USB stick with a dosfs is mounted without problems, is that because the type dosfs_t is known by hal et al.? What if there is a drive with neither dos nor ext3? Maybe the trick with chcon root this should go to the FAQ, or somewhere to the commmon issues page of fedora wiki: http://fedoraproject.org/wiki/Bugs/FC5Common
Hal should mount all removable devices as removable_t whether they have ext3 or not. It would be nice to be able to use xattrs if they are present, but I am not sure they should be trusted anyways.
Fedora Core 5 is no longer maintained. Is this bug still present in Fedora 7 or Fedora 8?
Fedora apologizes that these issues have not been resolved yet. We're sorry it's taken so long for your bug to be properly triaged and acted on. We appreciate the time you took to report this issue and want to make sure no important bugs slip through the cracks. If you're currently running a version of Fedora Core between 1 and 6, please note that Fedora no longer maintains these releases. We strongly encourage you to upgrade to a current Fedora release. In order to refocus our efforts as a project we are flagging all of the open bugs for releases which are no longer maintained and closing them. http://fedoraproject.org/wiki/LifeCycle/EOL If this bug is still open against Fedora Core 1 through 6, thirty days from now, it will be closed 'WONTFIX'. If you can reporduce this bug in the latest Fedora version, please change to the respective version. If you are unable to do this, please add a comment to this bug requesting the change. Thanks for your help, and we apologize again that we haven't handled these issues to this point. The process we are following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp We will be following the process here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this doesn't happen again. And if you'd like to join the bug triage team to help make things better, check out http://fedoraproject.org/wiki/BugZappers
This bug is open for a Fedora version that is no longer maintained and will not be fixed by Fedora. Therefore we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen thus bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.