lkml.org 
[lkml]   [2006]   [Apr]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectCLONE_NEWNS and mount command?
From
Date
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?
/* 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);
}
}
\
 
 \ /
  Last update: 2006-04-27 14:59    [W:0.042 / U:1.256 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site