[Pkg-sysvinit-devel] Bug#494001: debian-installer: /etc/mtab must be a symlink to /proc/mounts with linux >= 2.6.26

[Roger Leigh]

Hi Petter,

On Tue, Nov 08, 2011 at 11:44:05PM +0100, Petter Reinholdtsen wrote:
> 
> [Roger Leigh]
> > I've attached a new patch against the current sources to implement
> > this.  Note that it only handles migration in one direction, that
> > it, it will not switch /back/ from a symlink in the absence of
> > /proc/mounts.  While this could be added, is this a situation we
> > really need to cater for?
> 
> Last time I checked, /proc/mounts did not contain all the status
> information stored by mount in /etc/mtab, and thus were not really safe
> to use in all cases as a replacement for /etc/mtab.  I do not remember
> the details, but it might have been related to SMB mounts.
>
> Did this change?  If not, replacing /etc/mtab with a symlink is not
> really safe to do.

It is now.  There are two primary reasons:

1) The kernel can now store additional mount options and present them
   in /proc/mounts.  This was done in 2.6.2x IIRC.
2) util-linux libmount is used by the mount helpers such as mount.nfs
   to store additional stuff in /run/utab.  This handles the case
   where (1) is insufficient, and isn't normally needed.

The groundwork is all in place.  The major users (NFS, CIFS/SMB) are
already converted.  The remaining known tool (libpam-mount, #622693)
is fixed upstream and just waiting on a new util-linux (pending today).
Fedora made the change in Feb/March and have been mtabless for two
releases now.  It's time for us to do the same, I think, and get it
tested well before freezing.

I've been running with it as a symlink since the /run introduction,
which necessitated testing it.  I've not found any problems so far,
though obviously I can't have tested every filesystem mount option.

> I believe that before this change is introduced, someone should check if
> everything previously stored in /etc/mtab will be included in
> /proc/mounts, at least for nfs, smb/cifs, fuse (like sshfs and others),
> to make sure we do not introduce a regression.

This is done, TTBOMK.  I've pushed to get all the major mount helpers
to use libmount (where required).  NFS needed it; CIFS did not.  This
is just the last step of work starting in March. It's likely there are
going to be minor tools which may need conversion to use libmount, but
most work automatically with (1) above, and so don't require code
changes.  Basically, the rule of thumb is that direct editing of
/etc/mtab is no longer allowed--libmount handles this for you, and
stores the options in the appropriate place.

> I am aware that the new "container" stuff in Linux make /proc/mounts
> content not match the stuff in /etc/mtab if processes have limited
> access/view, but am not sure if that is a bigger problem than loosing
> information in /etc/mtab that might be needed by umount.

I think we're at or past the point where the cost of keeping mtab
outweigh the benefits.  It's not just containers; looking at the bug
list for util-linux, the number of mtab-related bugs is /huge/.  mount
--rbind is fundamentally broken, and several other mount options result
in broken mtabs which are inconsistent with /proc/mounts (missing or
incorrect entries, not even considering the mount options issue above).
These are much more commonly used than per-process namespaces, and are
utterly broken, and fixed by making it a symlink.  The result is that
the mtab contents are always consistent, and you can't get yourself
into the situation where you can't unmount things and get problems
due to the inconsistencies.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux             http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?       http://gutenprint.sourceforge.net/
   `-    GPG Public Key: 0x25BFB848   Please GPG sign your mail.