Red Hat Bugzilla – Bug 188193
util-linux should provide plugin infrastructure for HAL
Last modified: 2013-03-05 22:45:32 EST
Something seems to be automounting a DVD when I insert it, but without adding
the matching entries to /etc/fstab
This means that eject(1) fails:
shinybook /home/dwmw2 $ eject /dev/dvd
umount: /media/DVD_VIDEO is not in the fstab (and you are not root)
eject: unmount of `/media/DVD_VIDEO' failed
shinybook /home/dwmw2 $ umount /dev/dvd
umount: /dev/hdc is not in the fstab (and you are not root)
Even just pressing the eject button on the keyboard fails -- I see the eject
icon flash up on the middle of the screen and 'lshal --monitor' shows:
computer_logicaldev_input_0 condition ButtonPressed = ejectcd
... but I don't get the DVD back.
When file systems are automatically mounted, the corresponding entries need to
be put into /etc/fstab so that normal system utilities are aware of the situation.
Not sure it's a regression since you can still unmount/eject using Nautilus,
location computer:/// or even using the desktop icon.
> Even just pressing the eject button on the keyboard fails -- I see the eject
> icon flash up on the middle of the screen and
Needs fixing in gnome-settings-daemon. Please file separate bug (or clone this one).
> 'lshal --monitor' shows: computer_logicaldev_input_0 condition ButtonPressed =
Needs fixing in gnome-volume-manager. Please file separate bug (or clone this one).
> When file systems are automatically mounted, the corresponding entries need to
> be put into /etc/fstab so that normal system utilities are aware of the
Not going to happen. We could on the other hand patch mount(8) and eject(1) to
do query HAL and then DTRT.
Changing Summary to something more appropriate.
It is definitely a regression. The keyboard's eject button and the standard
eject(1) and umount(8) tools used to work in FC4. They don't now.
Hacking core utilities to query HAL or which GNOME system du jour is _not_ 'the
right thing'. The upper layers of the system should work _with_ the standard
tools, not against them. In this case, that means writing appropriate
information to /etc/fstab. To do otherwise is bizarre.
The change to the bug's Summary seems wrong but it's Ray's bug (since you told
me that this was the package to file it against), so I'll leave that to him.
> It is definitely a regression. The keyboard's eject button and the standard
> eject(1) and umount(8) tools used to work in FC4. They don't now.
These are bugs and I asked you to file them separately. Do you have the bug numbers?
> Hacking core utilities to query HAL or which GNOME system du jour
FYI, this has _nothing_ to do with GNOME...
> is _not_ 'the
> right thing'. The upper layers of the system should work _with_ the standard
> tools, not against them.
I don't see a problem changing eject(1) and umount(8) to ask HAL whether some
user may unmount a file system. HAL is a pretty central piece of the system
nowadays. I suggest you get used to it.
I agree it would be bad if some core utility like umount(8) would need to call
into the desktop but this is simply not the case.
> In this case, that means writing appropriate
> information to /etc/fstab. To do otherwise is bizarre.
This is just not going to happen. Period. (I'm the upstream HAL maintainer)
Don't get me wrong, I don't want to alienate command line users but the
direction we're taking the desktop in requires some changes that may sometimes
affect commandline users like yourself. That's why I asked you to file a bug so
we can find a good solution for the problem. Progress is hard.
> I don't see a problem changing eject(1) and umount(8) to ask HAL whether some
> user may unmount a file system. HAL is a pretty central piece of the system
> nowadays. I suggest you get used to it.
umount(8) is setuid -- simplicity is key. It always used to find the information
it needs in /etc/fstab. You haven't actually given any reason why we can't write
a temporary line to /etc/fstab when we mount a file system on behalf of the user.
Progress doesn't _need_ to be hard -- it doesn't need to gratuitously abandon
compatibility with existing tools and users. The shiny new upper layers of the
system need to _complement_ the system they're building on, not break it.
> umount(8) is setuid
Sigh. The whole point with hal is to allow unprivileged users to do actions like
mount, unmount, suspend, hibernate etc. in a highly controlled manner. A nice
side effect is that we don't need setuid binaries; for example, gnome-mount is
not setuid root.
As such, umount(8) just drops privileges when it decides to try hal for
unmounting. And this is doable as it's the last thing it will try.
So this patch to umount(8) should be simple and doable (since libdbus is now in
/lib, not /usr/lib) and I bet I could do it in 30 minutes or so.
> -- simplicity is key. It always used to find the
> information it needs in /etc/fstab.
'Always used to' is a bad excuse and you totally know it.
> You haven't actually given any reason why we can't write
> a temporary line to /etc/fstab when we mount a file system on behalf
> of the user.
Ok, here is where it is going to break
- multiple users logged in (including multiseat) -> we only want to allow the
user who mounted a device to unmount it
- CD's with multiple sessions/tracks since the kernel doesn't give us child
devices for each of these (Mac OS X does) -> umount only checks for the device name
It also breaks ro root unless you symlink /etc/fstab into /tmp.
> Progress doesn't _need_ to be hard -- it doesn't need to gratuitously abandon
> compatibility with existing tools and users. The shiny new upper layers of the
> system need to _complement_ the system they're building on, not break it.
We try as good as we can but sometimes the existing system is terribly broken.
Another reason is that you really want umount(8) to call Unmount() on HAL
otherwise the mount point created in /media might dangle.
I'm unconvinced, but feel free to go ahead and make these changes to core system
utilities. If, as you say, it's a 30-minute job, then we've spent more time
discussing it than it would take you to fix it.
This is a regression in FC5 and we need to fix it. And we need to pay more
attention in future, too.
Hi David (Zeuthen),
Are you working on a patch to integrate dbus with the mount tools in /bin ?
Karel, what are your thoughts on this?
yes, I can write these patches for umount and eject but I'm pretty busy these
days so it might take some time... of course it depends on whether the package
maintainers of eject and util-linux will take them so I'm not going to go ahead
and do this until I know they will be used.
Alright. kzak, do you think upstream would take a patch to make umount:
1) link against d-bus
2) use the HAL d-bus interfaces to unmount using HAL's policy in addition to the
current behavior of unmounting directly and basing policy on /etc/fstab.
> - multiple users logged in (including multiseat) -> we only want to allow the
> user who mounted a device to unmount it
The mount supports this check. You have to add "user=username" to the mount
options to /etc/mtab -- yeah, there still must be entry in /etc/fstab.
> do you think upstream would take a patch to make umount
There's a lot of more important and less exotic problems in util-linux which
are ignored by upstream now. Frankly, it sounds like strange idea for me and I'm
almost sure that it will be same for upstream.
The util-linux package is real core of linux OS and there should be minimum
dependences. Do you think that HAL/DBUS is low-level part of our distribution? I
don't think so. I think we shouln't mix low and high level things and if we need
to extend low-level part we should look for more common solution which is not
specific for one high-level program.
1/ add to the umount command warning message: "is it possible that some your
desktop application bypass standard way how system mounts devices. You should
use your desktop for umount if you use it for mount."
2/ the umount and mount commands already supports umount/mount by external
programs (e.g. /sbin/umount.cifs).
I think we can add new mount option "handler=<.postfix>" and if the mount/umount
command will found this option in /etc/mtab it will call
/sbin/[u]mount<.postfix> rather than remount/umount the device directly. It will
be more safe call the handler without root permissions if there is not user=,
users= or pamconsole=" option in /etc/fstab.
This solution is independent on DBUS/HAL. The /sbin/umount.dbus and
/sbin/mount.dbus could be in the hal package.
NEEDINFO_ENG has been deprecated in favor of NEEDINFO or ASSIGNED. Changing
status to ASSIGNED for ENG review.
Note D-Bus and HAL aren't really just for desktop applications. The fact that
they're primarily used for desktop applications is just an artifact of them
coming from the desktop team. Just out of curiosity, why does mount need to
check fstab in the first place? i.e., if the pamconsole option is sent to mount
then why isn't that sufficient for umount? is the option filtered out at some
David, what do you think of the handler= approach?
At any rate, this doesn't really have much to do with control-center, so i'm
moving to HAL.
Hi Karel, dwmw2, and Ray,
It would be fine with me if HAL could drop in handler/plugin/etc. to util-linux
so said handler would unmount via HAL's methods (that eventually will call
umount(8) as uid 0) if e.g. HAL mounts with "comment=mounted-via-hal".
That way it will "just work" unmounting filesystem's mounted in GNOME via
gnome-mount for commandline users like dwmw2 even when running unprivileged.
I want to reiterate however: gnome-mount / hal will never write to /etc/fstab
again - it just conflicts with the user experience we want on the desktop, e.g.
you can never do passworded media (e.g. LUKS) securely, nor can you ever provide
dialogs like these
without doing really nasty stuff.
Can we rename this bug to "util-linux should provide plugin infrastructure for
HAL" and reassign to util-linux? Just for tracking when this infrastructure is
Reassignig to util-linux.
any updates on this?
Too late for FC6. I expect resolution in the next development period. Sorry.
Then we need to fix the GUI tools so that /etc/fstab is kept in sync with
reality, as it used to be. This is a regression.
Changing Summary accordingly.
In response to comment 19: It's not a regression. FC5 worked exactly the same way.
We have a roadmap for how this will be fixed (the Summary you changed) and,
David, I'd appreciate if you would respect that not everyone else has the same
view as you on how the desktop UI should work.
Changing Summary back.
I'm not particularly interested in how the desktop UI works. What's important to
me is that the command line UI works. You've broken it. This used to work in
FC4, but doesn't now -- it's a regression; just not a _new_ one.
Expanding a bit why /etc/fstab does not make sense for desktop use.
We moved away from fstab-sync in FC5 because of the fact that it didn't allow
per-user settings for mount point and mount options. This is now in FC6, in the
gnome-mount-nautilus-properties package, and looks roughly like this
http://people.freedesktop.org/~david/gm-prop/gm-prop1.png and this
http://people.freedesktop.org/~david/gm-prop/gm-prop2.png - the UI needs some
work, hence why this package is not installed by default.
While we in theory could add an /etc/fstab entry *after* mounting the device
this is wrong too as it would allow any user at the console to unmount a device
mounted through gnome-mount. In fact, we're trying to move away from granting
privileges to do stuff like this iff the user is at the console to a much finer
grained level. In other words, I'm saying pam-console is broken by design, it
actually encourages using a coarse grained scheme like this.
This means that we'll be able to make a distinction between the action the user
is going to take and eventually we'll be able to grant very specific privileges
such as "is user allowed to mount a removable disk", "is user allowed to mount a
fixed disk", "is user allowed to connect to wireless network XYZ", "is user
allowed to format a disk" and so on. Specifically, we might one day want to add
the privilege "is user allowed to unmount other user's disks" and then your
suggestion with using /etc/fstab entries for mounted devices suddenly collapses.
That's the primary reason I'm against this - it's just the wrong direction,
especially when we have a good roadmap for meeting your wish.
For the longer explanation, please see, specifically page 25 and onwards
That said, you can easily use /bin/umount as root and the latest HAL 0.5.8 will
clean up the mount entry for you as it watches /proc/mounts. Whether we'll do
the HAL 0.5.7.1 to 0.5.8 upgrade for this release is another matter though.
I hope this clarifies.
In response to comment 21:
> I'm not particularly interested in how the desktop UI works.
> What's important to me is that the command line UI works.
It still works, you just get to use gnome-mount / gnome-umount / gnome-eject
instead. Heck, there's even a man page for these things and they even do more
than mount(8) / umount(8) / eject(1) does including persistent settings and LUKS
crypto devices. And no, it doesn't require an X server, I went that extra mile
because I do care about command line users.
Also, no one have removed the util-linux tools and you can still edit your
/etc/fstab file. Especially if you use the persistent device names in /dev/disk
and label the fs'es on your removable media accordingly it should work nicely
> You've broken it. This used to work in
> FC4, but doesn't now -- it's a regression; just not a _new_ one.
It's a _change_, not a regression. And only for command line users, heck, it's
even in the FC5 release notes
quoting from http://fedora.redhat.com/docs/release-notes/fc5/
> 7.13. No automatic fstab editing for removable media
> The fstab-sync facility has been removed. In Fedora Core , the fstab-sync
> program is removed in favor of desktop specific solutions for mounting
> removable media. Entries for hotplug devices or inserted media are no
> longer automatically added to the /etc/fstab file. Command-line users
> may migrate to gnome-mount, which provides similar functionality.
Besides, automounting was de facto broken prior to FC3 as it basically only
supported a hard-coded list of usb sticks and made wild assumptions about the
partition layout etc. etc.
I don't want to break stuff inadvertently, this bug is about making the
transition to gnome-mount as transparent as possible while still being able to
meet the goals mentioned comment 22. Right now, it's totally impossible to
sanely lock down stuff without crippling the system. A move to a fine grained
system (e.g. PolicyKit) will help a lot towards fixing that.
Hope this helps.
(In reply to comment #22)
> While we in theory could add an /etc/fstab entry *after* mounting the device
> this is wrong too as it would allow any user at the console to unmount a
> device mounted through gnome-mount.
Either I misunderstand you, or I think you misunderstand the current behaviour
of mount(8). It stores the user information in mtab, and only allows the user
who mounted the filesystem to unmount it. It doesn't allow any user to do so --
so it's simple to set it up so that only the user on whose behalf you mounted
the file system is able to unmount it from the command line (or through 'eject'
myth /home/dwmw2 $ whoami
myth /home/dwmw2 $ grep data /etc/fstab
LABEL=/data /data ext3 defaults,user 1 2
myth /home/dwmw2 $ mount /data
myth /home/dwmw2 $ sudo su mchehab
myth /home/dwmw2 $ umount /data
umount: only dwmw2 can unmount LABEL=/data from /data
As it stands, the 'eject /dev/dvd' which I have bound to the 'eject' key on my
keyboard is no longer functional. If you insist on keeping this behaviour,
please at least make sure the rest of the system is modified to keep up with it.
> Either I misunderstand you, or I think you misunderstand the current behaviour
> of mount(8). It stores the user information in mtab, and only allows the user
> who mounted the filesystem to unmount it. It doesn't allow any user to do
> so -- so it's simple to set it up so that only the user on whose behalf
> you mounted the file system is able to unmount it from the command line
> (or through 'eject' etc.)
No, I think you misunderstand how it works. To mount without /etc/fstab entries
for an unprivileged user, obviously you need a privileged helper. In this case,
the privileged helper is invoked by HAL in response to the Mount() method call.
This helper invokes mount(8). See page 17 of this presentation for the call sequence
Hence, it is uid 0 that mounts this on behalf of the user. Hence there is no
user=davidz or whatever in /etc/mtab. It's possible we could just pass that
option -ouser=<calling_user> to mount(8) from the commandline... in fact, I
wanted to do that initially but mount(8) (understandbly) fails when doing that.
If anything knows how to rectify this, I'll be happy to fix HAL to set the
user=<calling_user> option. Then, who knows, umount(8) and eject(1) might start
to work for you.
> As it stands, the 'eject /dev/dvd' which I have bound to the 'eject' key on
> my keyboard is no longer functional. If you insist on keeping this
> behaviour, please at least make sure the rest of the system is modified
> to keep up with it.
This should work out of the box. It's just a bug if it doesn't.
If you get an event from 'lshal --monitor' when pressing eject on you Apple
hardware (works on my Macbook Pro) then file a bug against gnome-volume-manager.
If you don't, then file a bug against HAL. In either case please Cc me on the
bug and I will fix it. My gut feeling is that it's g-v-m because getting the
'eject' event from a keyboard rather than the drive is unusual but such is Apple
Even if you have to modify /etc/mtab yourself to add the user option, it really
shouldn't be that hard. A simple patch to mount to make _that_ work, rather than
the whole plugin thing, should also be feasible for FC6.
can you setreuid(uid_of_davidz, 0) before execing mount and just pass user as
the option (without the =davidz)?
> Even if you have to modify /etc/mtab yourself to add the user option, it
> really shouldn't be that hard.
It would be racy for me to change it - would have to make assumptions on how
util-linux locks the file and it includes atomic updates etc. etc.
I'm all for this happening in util-linux though but even if we did this, it
would have to be accepted upstream in a release before we can put it in HAL
upstream. And then track history of util-linux doing releases and accepting
patches is not exactly something that faciliates this.
> can you setreuid(uid_of_davidz, 0) before execing mount and just pass
> user as the option (without the =davidz)?
No, that does't work unfortunately.
I don't expect anything than that the umount command will call /sbin/umount.hal
if there is "handler=hal" option in /etc/mtab. That's all. I will try prepare
this patch this week.
(Note, add user= or users option to the /etc/mtab file is not enough. The umount
command checks also /etc/fstab for same setting.)
David (Z.), you can try to implement and add to gnome-mount new helper
"/sbin/umount.hal". The mount and umount in util-linux-2.13-0.41 supports
"uhelper=" option now.
The syntax of external umount helpers is:
/sbin/umount.<suffix> [-nlfvr] dir | device
where the <suffix> is filesystem type or a value from "uhelper=" mtab option.
The uhelper (unprivileged umount request helper) is possible used when non-root
user wants to umount a mountpoint which is not defined in the /etc/fstab file
(e.g devices mounted by HAL).
# cat /sbin/umount.hal
echo "I'm dummy HAL umount, called with:"
echo "$0 $*"
# mount /mnt/test -ouhelper=hal
# grep uhelper /etc/mtab
/dev/dm-1 /mnt/test ext3 rw,uhelper=hal 0 0
$ umount /mnt/test
I'm dummy HAL umount, called with:
... so it works! :-)
Note, don't expect that this change in util-linux will be accepted by util-linux
upstream ASAP. The util-linux upstream is almost dead... (maybe I will take over
util-linux upstream in next moths...). I think you can try (temporary) to use
uhelper= as FC/RHEL specific solution.
Assigning back to HAL.
Upstream util-linux isn't dead. It's been taken over by Adrian Bunk, I believe.
<noflame> Adrian Bunk = dead upstream... </>
Ask him for something about util-linux... We have 82 patches in this package,
Suse is almost same.
Well, few mins ago I sent mail to Adrian with question about his plans with
util-linux upstream. We will see...
Hi, so I finally looked at doing this; looks like there's a deadlock, when
/sbin/umount.hal calls into hald then a helper of hald invokes umount, as root,
but that fails with
"Cannot create link /etc/mtab~"
Probably the fix is easy - just make sure to call helpers after you've cleaned
up the temporary /etc/mtab~ file? I tried making hald pass -n to the umount
instance invoked through umount.hal but that left the entry hanging.
huh, now I can't seem to reproduce this deadlock... perhaps the /etc/mtab~ file
was left over by emacs.. I was editing the /etc/mtab file to add the uhelper=hal
option. Probably so.
OK, I've committed this upstream
I'll enable it in Rawhide in a few days when I have a few more fixes / changes
ready. Thanks for doing providing plug-in infrastructure and sorry for being so
late in actually using it.
(In reply to comment #36)
> OK, I've committed this upstream
> I'll enable it in Rawhide in a few days when I have a few more fixes / changes
> ready. Thanks for doing providing plug-in infrastructure and sorry for being so
> late in actually using it.
Note, Fedora/RHEL (and probably others distros) will use
new util-linux upstream (http://userweb.kernel.org/~kzak/util-linux-ng/). My
plan is add "uhelper= "suppor to upstream code too.