This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 186148 - external usbdisk doesn't show up in mtab, audit avc messages
external usbdisk doesn't show up in mtab, audit avc messages
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: hal (Show other bugs)
5
i586 Linux
medium Severity low
: ---
: ---
Assigned To: David Zeuthen
bzcl34nup
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-03-21 16:38 EST by Tim Püschel
Modified: 2013-03-05 22:45 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-05-06 11:36:05 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
excerpt of /var/log/messages (4.64 KB, text/plain)
2006-03-21 16:38 EST, Tim Püschel
no flags Details

  None (edit)
Description Tim Püschel 2006-03-21 16:38:27 EST
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
Comment 1 Tim Püschel 2006-03-21 16:38:28 EST
Created attachment 126434 [details]
excerpt of /var/log/messages
Comment 2 Tim Püschel 2006-03-23 11:56:22 EST
the problem still exists with selinux-policy-targeted 2.2.25-2.fc5
Comment 3 Mike Bonnet 2006-03-28 13:50:05 EST
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 ~]$
Comment 4 Tim Püschel 2006-03-28 14:23:43 EST
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
Comment 5 Daniel Walsh 2006-03-28 14:41:59 EST
Could you try out restorecond?

chkconfig --add restorecond

service restorecond start
Comment 6 Mike Bonnet 2006-03-28 14:54:59 EST
To get restorecond I need policycoreutils from rawhide?  Is this compatible with
FC5?
Comment 7 Daniel Walsh 2006-03-28 14:58:51 EST
It is but, you can grab the one in fc5-test which will be released tonight.

Rather than updating to the latest tool chain.
Comment 8 Mike Bonnet 2006-03-28 15:22:57 EST
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?
Comment 9 Tim Püschel 2006-03-28 15:42:23 EST
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.
Comment 10 Tim Püschel 2006-03-31 09:31:05 EST
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. 

Comment 11 Daniel Walsh 2006-03-31 09:47:16 EST
Are you seeing AVC message?
Comment 12 Tim Püschel 2006-03-31 10:03:55 EST
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 ...
Comment 13 Mike Bonnet 2006-03-31 10:46:01 EST
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.
Comment 14 Tim Püschel 2006-03-31 11:42:59 EST
Yes, that did the trick. It works without problems now.

Thank you both.
Comment 15 Dan O'Brien 2006-03-31 22:10:02 EST
(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!

Comment 16 Gérard Milmeister 2006-04-03 17:06:31 EDT
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
Comment 18 Daniel Walsh 2006-05-09 16:48:45 EDT
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.
Comment 19 petrosyan 2008-03-10 22:03:45 EDT
Fedora Core 5 is no longer maintained. Is this bug still present in Fedora 7 or
Fedora 8?
Comment 20 Bug Zapper 2008-04-03 22:11:13 EDT
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
Comment 21 Bug Zapper 2008-05-06 11:36:04 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.