[RFC] obsoleting /etc/mtab

[RFC] obsoleting /etc/mtab

[Miklos Szeredi]

I started working on adding support for unprivileged mounts[1] to
util-linux.

The big obstacle seems to be the reliance on /etc/mtab, since that
won't be kept up-to-date after mount(2) or umount(2) calls by
unprivileged users.

It's not just mount(8) that reads /etc/mtab, but various other
utilities, for example df(1).  So the best solution would be if
/etc/mtab were a symlink to /proc/mounts, and the kernel would be the
authoritative source of information regarding mounts.

This works quite well already, but there are minor problems:

(1) user mounts ("user" or "users" option in /etc/fstab) currently
    need /etc/mtab to keep track of the owner

(2) lots of filesystems only present a few mount options (or none) in
    /proc/mounts

(1) can be solved with the new mount owner support in the unprivileged
mounts patchset.  Mount(8) would still have to detect at boot time if
this is available, and either create the symlink to /proc/mounts or if
MS_SETOWNER is not available, fall back to using /etc/mtab.

(2) needs work in the filesystems implicated.  I already have patches
for ext2, ext3, tmpfs, devpts and hostfs, and it would be nice if the
maintainers for others could help out.

It wouldn't even be fatal if some mount options were missing from
/proc/mounts.  Mount options in /etc/mtab have never been perfectly
accurate, especially after a remount, when they could get totally out
of sync with the options effective for the filesystem.

Can someone think of any other problem with getting rid of /etc/mtab?

Thanks,
Miklos

[1] http://lkml.org/lkml/2007/4/27/180

Re: [RFC] obsoleting /etc/mtab

[H. Peter Anvin]

Miklos Szeredi wrote:
> 
> (2) needs work in the filesystems implicated.  I already have patches
> for ext2, ext3, tmpfs, devpts and hostfs, and it would be nice if the
> maintainers for others could help out.
> 

A lot of these could be fixed all at once by letting the filesystem tell
the VFS to retain the string passed to the original mount.  That will
solve *almost* all filesystems which take string options.

On the other hand, maybe it's cleaner to present a canonical view of the
options.  Note that /etc/mtab does not, however.

	-hpa

Re: [RFC] obsoleting /etc/mtab

[Miklos Szeredi]

> > 
> > (2) needs work in the filesystems implicated.  I already have patches
> > for ext2, ext3, tmpfs, devpts and hostfs, and it would be nice if the
> > maintainers for others could help out.
> > 
> 
> A lot of these could be fixed all at once by letting the filesystem tell
> the VFS to retain the string passed to the original mount.  That will
> solve *almost* all filesystems which take string options.

On remount some filesystems like ext[234] use the given options as a
delta, not as the new set of options.  Others just ignore some of the
options on remount.

Yes, /etc/mtab is broken wrt. remount too, but somehow I feel breaking
/proc/mounts this way too would be frowned upon.

> On the other hand, maybe it's cleaner to present a canonical view of the
> options.  Note that /etc/mtab does not, however.

Yes, we could emulate /etc/mtab like this for filesystems which don't
have a ->show_options(), but mostly filesystems do have
->show_options(), they are just lazy about updating it with all the
new mount options.

Miklos

Re: [RFC] obsoleting /etc/mtab

[Karel Zak]

On Thu, May 31, 2007 at 09:40:49AM -0700, H. Peter Anvin wrote:
> Miklos Szeredi wrote:
> > 
> > (2) needs work in the filesystems implicated.  I already have patches
> > for ext2, ext3, tmpfs, devpts and hostfs, and it would be nice if the
> > maintainers for others could help out.
> > 
> 
> A lot of these could be fixed all at once by letting the filesystem tell
> the VFS to retain the string passed to the original mount.  That will

 Unfortunately, the original option string (from userspace) != real
 options (in kernel), see NFS. This bug should be fixed -- the kernel
 has to fully follow mount(2) or ends with EINVAL.

    Karel

-- 
 Karel Zak  <kzak-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>

Re: [RFC] obsoleting /etc/mtab

[Trond Myklebust]

On Fri, 2007-06-01 at 01:04 +0200, Karel Zak wrote:
> On Thu, May 31, 2007 at 09:40:49AM -0700, H. Peter Anvin wrote:
> > Miklos Szeredi wrote:
> > > 
> > > (2) needs work in the filesystems implicated.  I already have patches
> > > for ext2, ext3, tmpfs, devpts and hostfs, and it would be nice if the
> > > maintainers for others could help out.
> > > 
> > 
> > A lot of these could be fixed all at once by letting the filesystem tell
> > the VFS to retain the string passed to the original mount.  That will
> 
>  Unfortunately, the original option string (from userspace) != real
>  options (in kernel), see NFS. This bug should be fixed -- the kernel
>  has to fully follow mount(2) or ends with EINVAL.

Way ahead of you... See patches 6 and 7 on

  http://client.linux-nfs.org/Linux-2.6.x/2.6.22-rc3/

Trond

Re: [RFC] obsoleting /etc/mtab

[H. Peter Anvin]

Trond Myklebust wrote:
>>>>
>>> A lot of these could be fixed all at once by letting the filesystem tell
>>> the VFS to retain the string passed to the original mount.  That will
>>  Unfortunately, the original option string (from userspace) != real
>>  options (in kernel), see NFS. This bug should be fixed -- the kernel
>>  has to fully follow mount(2) or ends with EINVAL.
> 
> Way ahead of you... See patches 6 and 7 on
> 
>   http://client.linux-nfs.org/Linux-2.6.x/2.6.22-rc3/
> 

NFS takes a binary option block anyway.  However, that's the exception,
not the rule.

	-hpa

Re: [RFC] obsoleting /etc/mtab

[Andreas Dilger]

On May 31, 2007  17:11 -0700, H. Peter Anvin wrote:
> NFS takes a binary option block anyway.  However, that's the exception,
> not the rule.

There was recently a patch submitted to linux-fsdevel to change NFS to
use text option parsing.

Cheers, Andreas
--
Andreas Dilger
Principal Software Engineer
Cluster File Systems, Inc.

Re: [RFC] obsoleting /etc/mtab

[Karel Zak]

On Thu, May 31, 2007 at 05:11:40PM -0700, H. Peter Anvin wrote:
> Trond Myklebust wrote:
> >>>>
> >>> A lot of these could be fixed all at once by letting the filesystem tell
> >>> the VFS to retain the string passed to the original mount.  That will
> >>  Unfortunately, the original option string (from userspace) != real
> >>  options (in kernel), see NFS. This bug should be fixed -- the kernel
> >>  has to fully follow mount(2) or ends with EINVAL.
> > 
> > Way ahead of you... See patches 6 and 7 on
> > 
> >   http://client.linux-nfs.org/Linux-2.6.x/2.6.22-rc3/

  :-)

> NFS takes a binary option block anyway.  However, that's the exception,
> not the rule.

 I'm not sure, but I think that cifs and ncpfs (NetWare) are
 exceptions too.

    Karel

-- 
 Karel Zak  <kzak@redhat.com>

Re: [RFC] obsoleting /etc/mtab

[Jan Engelhardt]

On Jun 1 2007 09:35, Karel Zak wrote:
>
>> NFS takes a binary option block anyway.  However, that's the exception,
>> not the rule.
>
> I'm not sure, but I think that cifs and ncpfs (NetWare) are
> exceptions too.

And the dying smbfs...



	Jan
-- 

Re: [RFC] obsoleting /etc/mtab

[David Chinner]

On Thu, May 31, 2007 at 09:40:49AM -0700, H. Peter Anvin wrote:
> Miklos Szeredi wrote:
> > 
> > (2) needs work in the filesystems implicated.  I already have patches
> > for ext2, ext3, tmpfs, devpts and hostfs, and it would be nice if the
> > maintainers for others could help out.
> > 
> 
> A lot of these could be fixed all at once by letting the filesystem tell
> the VFS to retain the string passed to the original mount.  That will
> solve *almost* all filesystems which take string options.

Except some filesystems mangle that string as it gets passed around
(i.e. XFS)....

Cheers,

Dave.
-- 
Dave Chinner
Principal Engineer
SGI Australian Software Group

Re: [RFC] obsoleting /etc/mtab

[Karel Zak]

 Hi Miklos,

On Thu, May 31, 2007 at 06:29:12PM +0200, Miklos Szeredi wrote:
> It's not just mount(8) that reads /etc/mtab, but various other
> utilities, for example df(1).  So the best solution would be if

 mount.nfs, mount.cifs, mount.ocfs, HAL, am-utils (amd)...

 and these utils also write to mtab, although I think many of them already
 check for a symlink.

> /etc/mtab were a symlink to /proc/mounts, and the kernel would be the
> authoritative source of information regarding mounts.

 Yes.

> (1) user mounts ("user" or "users" option in /etc/fstab) currently
>     need /etc/mtab to keep track of the owner

 There is more things:

  loop=</dev/loopN>

      ... umount(8) uses this option for loop device deinitialization,
      when the device was initialized by mount(8),

  encryption=, offset=, speed=

       ... but nothing uses these options

  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).

       GNOME people love it, because that's a way how use command line
       utils (umount(8)) for devices that was mounted by desktop
       daemons.


 The umount.nfs also reads many options from mtab, but it seems all
 these options are also in /proc/mounts.

 I know almost nothing about the others [u]mount dialects (cifs, ...).

> (2) lots of filesystems only present a few mount options (or none) in
>     /proc/mounts
> 
> (1) can be solved with the new mount owner support in the unprivileged
> mounts patchset.  Mount(8) would still have to detect at boot time if
> this is available, and either create the symlink to /proc/mounts or if
> MS_SETOWNER is not available, fall back to using /etc/mtab.

 Sounds good, but there should be a way (an option) to disable this
 functionality (in case when mtab is required for an exotic reason).

> (2) needs work in the filesystems implicated.  I already have patches
> for ext2, ext3, tmpfs, devpts and hostfs, and it would be nice if the
> maintainers for others could help out.
> 
> It wouldn't even be fatal if some mount options were missing from
> /proc/mounts.  Mount options in /etc/mtab have never been perfectly
> accurate, especially after a remount, when they could get totally out
> of sync with the options effective for the filesystem.

 The /etc/mtab is almost always useless with NFS (kernel is changing
 mount options according to NFS server settings, so there is possible
 that you have "rw" in mtab and "ro" in /proc/mounts :-)

> 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.

> [1] http://lkml.org/lkml/2007/4/27/180

 The patches have been postponed by Andrew, right? Or is it already in
 -mm?

    Karel

-- 
 Karel Zak  <kzak-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>

Re: [RFC] obsoleting /etc/mtab

[Miklos Szeredi]

> On Thu, May 31, 2007 at 06:29:12PM +0200, Miklos Szeredi wrote:
> > It's not just mount(8) that reads /etc/mtab, but various other
> > utilities, for example df(1).  So the best solution would be if
> 
>  mount.nfs, mount.cifs, mount.ocfs, HAL, am-utils (amd)...

OK, I'll try to round up the people involved and ask how this change
would affect their programs.

> > (1) user mounts ("user" or "users" option in /etc/fstab) currently
> >     need /etc/mtab to keep track of the owner
> 
>  There is more things:
> 
>   loop=</dev/loopN>
> 
>       ... umount(8) uses this option for loop device deinitialization,
>       when the device was initialized by mount(8),

Hmm, this is basically just a bool flag for each loop device, and
could be stored in a file under /var/lib.

>   encryption=, offset=, speed=
> 
>        ... but nothing uses these options
> 
>   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?

> 
>        GNOME people love it, because that's a way how use command line
>        utils (umount(8)) for devices that was mounted by desktop
>        daemons.
> 
> 
>  The umount.nfs also reads many options from mtab, but it seems all
>  these options are also in /proc/mounts.
> 
>  I know almost nothing about the others [u]mount dialects (cifs, ...).
> 
> > (2) lots of filesystems only present a few mount options (or none) in
> >     /proc/mounts
> > 
> > (1) can be solved with the new mount owner support in the unprivileged
> > mounts patchset.  Mount(8) would still have to detect at boot time if
> > this is available, and either create the symlink to /proc/mounts or if
> > MS_SETOWNER is not available, fall back to using /etc/mtab.
> 
>  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.

> > (2) needs work in the filesystems implicated.  I already have patches
> > for ext2, ext3, tmpfs, devpts and hostfs, and it would be nice if the
> > maintainers for others could help out.
> > 
> > It wouldn't even be fatal if some mount options were missing from
> > /proc/mounts.  Mount options in /etc/mtab have never been perfectly
> > accurate, especially after a remount, when they could get totally out
> > of sync with the options effective for the filesystem.
> 
>  The /etc/mtab is almost always useless with NFS (kernel is changing
>  mount options according to NFS server settings, so there is possible
>  that you have "rw" in mtab and "ro" in /proc/mounts :-)
> 
> > 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.

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.

> > [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 ;)

Miklos

Re: [RFC] obsoleting /etc/mtab

[Karel Zak]

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-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>

Re: [RFC] obsoleting /etc/mtab

[Christoph Hellwig]

On Fri, Jun 01, 2007 at 10:33:09AM +0200, Karel Zak wrote:
>  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.

Please don't put this in.  The last thing we need is more ugly hacks
and suid mess in the mount code.  Miklos is working towards proper
non-privilegued mounts and you should better support him there.

Re: [RFC] obsoleting /etc/mtab

[Karel Zak]

On Fri, Jun 01, 2007 at 09:49:05AM +0100, Christoph Hellwig wrote:
> On Fri, Jun 01, 2007 at 10:33:09AM +0200, Karel Zak wrote:
> >  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.
> 
> Please don't put this in.  The last thing we need is more ugly hacks
> and suid mess in the mount code.  Miklos is working towards proper

 suid mess? Fortunately, we use external umount programs for all
 network filesystems.

> non-privilegued mounts and you should better support him there.

 Yes, I look forward to his patches, but there is still a fstab check
 in umount. The current umount(8) code expects "user" or "users" option
 in /etc/mtab (or in Miklos's /proc/mounts) and *also* in /etc/fstab.

 Maybe the umount(8) code is too much paranoid and we needn't the
 fstab check, especially with non-suid umount(2). Miklos's patches
 also add support for "a submount under the owned mount" -- this is
 probably next situation when check against fstab is useless.

    Karel

-- 
 Karel Zak  <kzak-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>

Re: [RFC] obsoleting /etc/mtab

[Miklos Szeredi]

> On Fri, Jun 01, 2007 at 09:49:05AM +0100, Christoph Hellwig wrote:
> > On Fri, Jun 01, 2007 at 10:33:09AM +0200, Karel Zak wrote:
> > >  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.
> > 
> > Please don't put this in.  The last thing we need is more ugly hacks
> > and suid mess in the mount code.  Miklos is working towards proper
> 
>  suid mess? Fortunately, we use external umount programs for all
>  network filesystems.
> 
> > non-privilegued mounts and you should better support him there.
> 
>  Yes, I look forward to his patches, but there is still a fstab check
>  in umount. The current umount(8) code expects "user" or "users" option
>  in /etc/mtab (or in Miklos's /proc/mounts) and *also* in /etc/fstab.
> 
>  Maybe the umount(8) code is too much paranoid and we needn't the
>  fstab check, especially with non-suid umount(2). Miklos's patches
>  also add support for "a submount under the owned mount" -- this is
>  probably next situation when check against fstab is useless.

This is a crucial question.  The unpriv patches assume, that the owner
can unmount, regardless of what's in fstab.

The question is: why does umount(8) currently check /etc/fstab?  I can
imagine, that this is a sort of sanity check, if the mount is really
the same as it was (hasn't been moved, remounted, umounted etc).

In this case it's OK to get rid of this check, since the kernel will
know if something happened to the mount.

Or is there some other reason for checking fstab on umount?

Miklos

Re: [RFC] obsoleting /etc/mtab

[Karel Zak]

On Fri, Jun 01, 2007 at 11:53:13AM +0200, Miklos Szeredi wrote:
> > On Fri, Jun 01, 2007 at 09:49:05AM +0100, Christoph Hellwig wrote:
> > > On Fri, Jun 01, 2007 at 10:33:09AM +0200, Karel Zak wrote:
> > > >  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.
> > > 
> > > Please don't put this in.  The last thing we need is more ugly hacks
> > > and suid mess in the mount code.  Miklos is working towards proper
> > 
> >  suid mess? Fortunately, we use external umount programs for all
> >  network filesystems.
> > 
> > > non-privilegued mounts and you should better support him there.
> > 
> >  Yes, I look forward to his patches, but there is still a fstab check
> >  in umount. The current umount(8) code expects "user" or "users" option
> >  in /etc/mtab (or in Miklos's /proc/mounts) and *also* in /etc/fstab.
> > 
> >  Maybe the umount(8) code is too much paranoid and we needn't the
> >  fstab check, especially with non-suid umount(2). Miklos's patches
> >  also add support for "a submount under the owned mount" -- this is
> >  probably next situation when check against fstab is useless.
> 
> This is a crucial question.  The unpriv patches assume, that the owner
> can unmount, regardless of what's in fstab.

 Yes.

> The question is: why does umount(8) currently check /etc/fstab?  I can

 I think I found why. See

 http://git.kernel.org/?p=utils/util-linux-ng/util-linux-ng.git;a=blob;f=mount/umount.c;h=c3cfee71aa0c0072b67a128f0956be6a01f3d4ac;hb=6dbe3af945a63f025561abb83275cee9ff06c57b

 that's umount(8) from util-linux-2.2 (year 1995). There is fstab check
 *only*. It seems that there wasn't originally a "user=" option in
 /etc/mtab...

 ... around version 2.9 has been added mtab check and "user=" is
 in fstab and mtab now.

 IMHO the fstab check is legacy.

> imagine, that this is a sort of sanity check, if the mount is really
> the same as it was (hasn't been moved, remounted, umounted etc).
> 
> In this case it's OK to get rid of this check, since the kernel will
> know if something happened to the mount.

 Yes.

    Karel

-- 
 Karel Zak  <kzak-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>

Re: [RFC] obsoleting /etc/mtab

[Matthias Koenig]

Karel Zak <kzak-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> writes:

>  There is more things:
>
>   uhelper=
>
>        ... this one is my baby :-(
>
>        (Not released by upstream yet.  ...according to Google this
>        Fedora patch is already in Mandrake, PCLinuxOS, Pardus, and
>        ??? )

and openSuse Factory...

>  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.

I agree, we need a way to store userspace specific options.  
E.g. Suse has also a way to tag NFSv4 export directories which are 
automatically mounted via bind to the main export directory with an
own option and relies on that this option gets propagated to mtab
without modification.

Matthias

Re: [RFC] obsoleting /etc/mtab

[Roman Zippel]

On Thu, 31 May 2007, Miklos Szeredi wrote:

> Can someone think of any other problem with getting rid of /etc/mtab?

loop mounts were already mentioned. Another is chroots, currently all 
mounts are visible in any chroot.

bye, Roman

Re: [RFC] obsoleting /etc/mtab

[Ian Kent]

On Thu, 2007-05-31 at 18:29 +0200, Miklos Szeredi wrote:
> I started working on adding support for unprivileged mounts[1] to
> util-linux.
> 
> The big obstacle seems to be the reliance on /etc/mtab, since that
> won't be kept up-to-date after mount(2) or umount(2) calls by
> unprivileged users.

snip ...

> Can someone think of any other problem with getting rid of /etc/mtab?

This presents a couple of problems for autofs, version 5.

First, autofs will function if /etc/mtab is a symlink to /proc/mounts
(or better if we could mount /proc/mounts as the "file" /etc/mtab). 

There are however two problems, first for people that have a large
number of mounts, particularly direct mounts, the listing of mounts
would be terrible. An implementation of automount on an old version of
AIX did this and it was just about impossible to tell what mounts where
present besides the autofs internal mounts. Solaris uses a mount option,
"hide" or "hidden" or something which prevents them from being listed
and that works fine. We would need to do something like that in all the
utilities that read /etc/mtab.

The second, and also maybe not such a big issue, is that if there are
many autofs entries to read through this has the potential to kill
autofs performance for mounting, expiring and checking if something is
mounted, whether the entries have a hidden flag or not utilities will
still need to read through all the entries. The same performance issue
applies for all the utilities that read the mount table. I'd expect a
typical small to medium site that makes wide use of direct mounts to
have between 500 and 1000 entries in their maps, and so 500 - 1000
autofs direct mount triggers, similar to Solaris. Also, people that have
large filers with many exports will have many internal autofs mounts if
using the commonly used "hosts" map, we use a different implementation
for this than Solaris so there are less internal autofs mounts than in
Solaris, but still many.

Ideas?

Ian

Re: [RFC] obsoleting /etc/mtab

[James Cloos]

>>>>> "Miklos" == Miklos Szeredi <miklos@szeredi.hu> writes:

Miklos> So the best solution would be if /etc/mtab were a symlink to
Miklos> /proc/mounts, and the kernel would be the authoritative source
Miklos> of information regarding mounts.

That would have to be a symlink to /proc/self/mounts, yes?

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6

Re: [RFC] obsoleting /etc/mtab

[H. Peter Anvin]

James Cloos wrote:
>>>>>> "Miklos" == Miklos Szeredi <miklos-sUDqSbJrdHQHWmgEVkV9KA@public.gmane.org> writes:
> 
> Miklos> So the best solution would be if /etc/mtab were a symlink to
> Miklos> /proc/mounts, and the kernel would be the authoritative source
> Miklos> of information regarding mounts.
> 
> That would have to be a symlink to /proc/self/mounts, yes?
> 

/proc/mounts *is* a symlink to /proc/self/mounts.

	-hpa

Re: [RFC] obsoleting /etc/mtab

[James Cloos]

>>>>> "Peter" == H Peter Anvin <hpa-YMNOUZJC4hwAvxtiuMwx3w@public.gmane.org> writes:

Peter> /proc/mounts *is* a symlink to /proc/self/mounts.

D’oh.  I must have read mounts where modules showed up in the ls(1) I ran
before writing that.  I probably should adjust the cyan used for symlinks
in the coloured ls(1) output; it does seem to blend in with the yellowish
background.  [SIGH]  Appologies for the noise. ;^(

-JimC
-- 
James Cloos <cloos-GRsvFm/Gh/pBDgjK7y7TUQ@public.gmane.org>         OpenPGP: 1024D/ED7DAEA6