On Tue, 31 Jan 2012 15:29:59 +0100 Laurent Bercot <[email protected]> wrote:
> > What the uhelper=xxx does, is that when user runs "umount /mnt", it > > calls the uhelper provided instead of kernel. It is then expected > > that the uhelper eventually calls again "umount -i /mnt" which does > > the umounting job. The idea is to hook umount calls, so that they > > send proper notifications to the UI about device being umounted. > > Going out on a limb here. Wouldn't it be cleaner for UI (or other) > parts that need it to listen - via inotify or something - > to /proc/mounts changes, instead of having to add hooks to every > command that can perform a mount/unmount ? I believe the other thing it does is additional policy and access control. E.g. if userA mounted removable deviceA, and userB tries to umount it, it can show a GUI dialog asking for credentials. Or something like that. Not really sure. However, that uhelper has also a veto right for the umount request. > > the uhelper (and non-root umount) stuff in a clean enough manner. > > The hook should really be at the mount(2) or umount(2) system call > level. Patching umount means that some user can write his own umount > command that will mess up the consistency of the stuff. > I would really advise looking for notifications that are sent by the > *kernel*, and add helpers there, instead of patching user-space tools. > > I'm even fairly sure mdev can be configured to do this. Yes, it should do this in addition to avoid the inconsitency issues. In matter of fact, the code seems to monitor /proc/self/mountinfo. Sounds like a bug there. Will look into it. In short, I think we can live without uhelper. And should probably ignore it silently, if not implement it. But the "umount" for mounts with "user" option in fstab should probably be implemented regardless. Or remove it from 'mount' too. - Timo _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
