CLONE_NEWNS and mount command?

CLONE_NEWNS and mount command?

[Tom Horsley]

[-- Attachment #1: Type: text/plain, Size: 965 bytes --]

I stumbled across the CLONE_NEWNS flag in the clone() man page and
thought I'd see if I could write a program that would let me do things
like run an sshd on my machine in a different "namespace" created
before any network filesystems were mounted (so I could run rpm
commands without NFS timeouts, etc).

In my experiments though, I got very confused. I created the attached
program, used it to exec an xterm, then in that xterm unmounted
a NFS filesystem.

It disappeared from the mounts listed by the "mount" command
in both the old and new namespace, but if I attempted to remount
the system in the old namespace I get an error telling me it is
already mounted (even though it doesn't show up). In the new
namespace where I unmounted it, I can remount it (then it shows
up again in the mount listing in both namespaces).

Should the /proc/mounts file be paying more attention to this
"namespace" thing? Is this a bug, or just the way things happen
to work out?

[-- Attachment #2: nomounts.c --]
[-- Type: text/x-csrc, Size: 917 bytes --]

/* Run a process in a new "namespace".
 */
#include <sched.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/wait.h>
#include <stdio.h>

#define STACK_SIZE ((20*4096)/sizeof(double))
static double stack_space[STACK_SIZE];

int
do_new_namespace(void * arg) {
   char ** argv = (char **)arg;
   execvp(argv[0], argv);
   perror("execvp");
   _exit(2);
}

int
main(int argc, char ** argv) {
   int clone_id;
   int wstat;
   pid_t kid;

   clone_id = clone(do_new_namespace, &stack_space[STACK_SIZE-2], CLONE_NEWNS,
                    (void *)(argv + 1));
   if (clone_id == -1) {
      perror("clone");
      _exit(2);
   }
   kid = waitpid((pid_t)clone_id, &wstat, 0);
   if (kid == (pid_t)-1) {
      perror("waitpid");
      _exit(2);
   }
   if ((kid == (pid_t)clone_id) && WIFEXITED(wstat)) {
      _exit(WEXITSTATUS(wstat));
   } else {
      _exit(2);
   }
}

Re: CLONE_NEWNS and mount command?

[Al Viro]

On Thu, Apr 27, 2006 at 08:57:20AM -0400, Tom Horsley wrote:
> It disappeared from the mounts listed by the "mount" command
> in both the old and new namespace, but if I attempted to remount
> the system in the old namespace I get an error telling me it is
> already mounted (even though it doesn't show up). In the new
> namespace where I unmounted it, I can remount it (then it shows
> up again in the mount listing in both namespaces).
> 
> Should the /proc/mounts file be paying more attention to this
> "namespace" thing? Is this a bug, or just the way things happen
> to work out?

Huh?  a) /proc/mounts is the list for namespace of one who'd opened it
(it's a symlink to /proc/self/mounts).  b) are you sure that you do
not simply end up with chewing shared /etc/mtab?

Re: CLONE_NEWNS and mount command?

[Tom Horsley]

On Thu, 2006-04-27 at 14:01 +0100, Al Viro wrote:
> Huh?  a) /proc/mounts is the list for namespace of one who'd opened it
> (it's a symlink to /proc/self/mounts).  b) are you sure that you do
> not simply end up with chewing shared /etc/mtab?

Very possible if there really is an mtab file these days. I was
sorta hoping that the mount command used the /proc/mounts. I should
do my experiment again looking only at /proc/mounts I guess.

If there is a bug, maybe it is that a /etc/mtab file exists
at all :-).

Re: CLONE_NEWNS and mount command?

[Michael Tokarev]

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