Bug 186148

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.