On Fri, Jun 01, 2007 at 09:03:42AM +0200, Miklos Szeredi wrote:
> > uhelper=
> >
> > ... this one is my baby :-(
> >
> > (Not released by upstream yet. ...according to Google this
> > Fedora patch is already in Mandrake, PCLinuxOS, Pardus, and
> > ??? )
> >
> > From man page:
> >
> > 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).
>
> So the helper gets to run _before_ the umount takes place?
The helper runs instead the umount(8). That's almost same like
/sbin/umount.nfs. For example if you have mtab:
/dev/foo /media/hal_hell_mnt iso9990 uhelper=hal
when you call as unprivileged user the /sbin/umount command:
it detects that you have no permissions, but that there is
/sbin/umount.hal and all is redirected (fork(), execv(), ...) to
the umount.hal. The umount(8) doesn't do anything with the
mointpoint in this case.
The core of the problem is that HAL doesn't have entries in
/etc/fstab, so you cannot check for "user=" and "users=" by
umount(8). The HAL have enough information about user's privileges,
but the umount(8) knows nothing.
http://git.kernel.org/?p=utils/util-linux-ng/util-linux-ng.git;a=commit;h=dd9f213ab6efd352f67bc18071c16239d1002b94
> > Sounds good, but there should be a way (an option) to disable this
> > functionality (in case when mtab is required for an exotic reason).
>
> Sure, that's a good idea. How do we configure mount(8)? Maybe an
> option (--no-mtab-symlink), and leave the configuration to userspace.
> When mount is invoked first on boot (mount -a) this could tell us if
> the creation of the symlink is not desired.
Yes. (The mount is invoked first with "-n" (= no mtab) in early boot
time, because the root device is mounted read-only. Later the init
scripts use "mount -f" which doesn't call mount(2), but adds things
to mtab only. In this time we need to use "--no-mtab-symlink). But that's
detail...)
> > > Can someone think of any other problem with getting rid of /etc/mtab?
> >
> > Crazy idea: make kernel more promiscuous with mount options -- it
> > means you can use an arbitrary "foo=" option for mount(2) when max
> > length of all options is less than or equal to
> > /proc/sys/fs/mntopt_max. (well... NACK :-)
> >
> > I agree that the /etc/mtab file is badly designed thing where we
> > duplicate almost all from /proc/mounts, but loop= and uhelper= are
> > nice examples that userspace utils are able to capitalize on this
> > concept. Maybe we need something better than the mtab for userspace
> > specific options.
> >
> > Somewhere at people.redhat.com/kzak/ I have a patch that add LUKS
> > support to the mount(8) and this patch also add new options to the
> > mtab file. I can imagine more scenarios when userspace specific
> > options are good thing.
>
> So there's a need to attach some metadata to mounts. And preferably
> that should also be stored in the kernel, otherwise there will just be
> confusion, when the mount tree is manipulated without the metadata
> also being updated. And with unprivileged mounts this can only be
> guaranteed if the metadata is also in the kernel.
There is more scenarios -- for example somewhere in RH bugzilla is
waiting request for "read-only root filesystem" -- in particular case
the writable /etc/mtab is problem.
> So, how about a special mount option: "uopts=...", which would contain
> userspace options separated by ";" or whatever. Then the kernel could
> be taught to store this option verbatim and show it in /proc/mounts
> along with the kernel options.
Yes, something like "uopts=..." is my wish for long time.
> > > [1] http://lkml.org/lkml/2007/4/27/180
> >
> > The patches have been postponed by Andrew, right? Or is it already in
> > -mm?
>
> Yes, they have now survived for a month in -mm, which might be a good
> sign ;)
Cool, good news.
Karel
--
Karel Zak <kzak@xxxxxxxxxx>
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
