Re: CLONE_NEWNS and mount command?

[Michael Tokarev <mjt@tls.msk.ru>]

Tom Horsley wrote:
[]
> If there is a bug, maybe it is that a /etc/mtab file exists
> at all :-).

This topic has been discussed before (without any real conclusion
if memory serves me right).  The thing is: /etc/mtab IS useful,
as it contains different information compared with /proc/mounts
(irrelevant to CLONE_NEWNS/namespaces).  For example, if I'll

  mount -o loop file /mount/point

mtab will contain
  -oloop=X /path/to/file /mount/point

while /proc/mounts will only have
  file /mount/point

Note the two differences: omission of loop device number (used
by umount to automatically deconfigure loop device) and relative
(to what??) path to `file'.

On the other hand, /proc/mounts often contains more options
than mtab: mtab only lists those options which has been specified
on the command line, omitting defaults, but /proc/mounts lists
them all (like data=ordered for ext3fs).

And on another note, there are cases when you do NOT want to
expose some "internal" mounts to users.  "Classical" example
which bothered me for quite some time is the way udev is set
up on Debian (dunno for other distros): they move-mount /dev
to /dev/.static/dev, but /dev/.static is drwx------, ie ordinary
users can't access it.  Hence, when you run any command which
tries to access mounted filesystems (like df for example), it
complains that it can't stat /dev/.static/dev, which is plain
ugly.  Omitting that entry from /etc/mtab fixes the problem.

That all to say: /proc/mounts and /etc/mtab both has their
good and usages...  And *this*, IMHO, is where the bug is:
neither of the two gives complete information.

/mjt