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 umount(8) fails: 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 = ejectcd 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 > situation. 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. My suggestion: 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." or 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.
Hi Karel, 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 point? 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 http://people.freedesktop.org/~david/gm-prop/ 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 available. Thanks, David
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 http://people.freedesktop.org/~david/talks/system-integration-and-gnome-guadec2006-davidz.pdf 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 for you. > 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' etc.) myth /home/dwmw2 $ whoami dwmw2 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 Password: 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 http://people.freedesktop.org/~david/talks/dynamic-device-handling-OLS-2006.pdf 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 hardware.
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)?
Comment 26: > 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. Comment 27: > 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. NOTES: 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). EXAMPLE: # cat /sbin/umount.hal #!/bin/bash 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: /sbin/umount.hal /mnt/test ... 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 http://gitweb.freedesktop.org/?p=hal.git;a=commitdiff;h=184afb9acb61816203c852ab3559a849248362d3;hp=56d25189e3173333c457b349496f0b1b1665b6dd 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 > http://gitweb.freedesktop.org/?p=hal.git;a=commitdiff;h=184afb9acb61816203c852ab3559a849248362d3;hp=56d25189e3173333c457b349496f0b1b1665b6dd > > 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. Thanks. 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.