All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Frysinger <vapier@gentoo.org>
To: Lubomir Rintel <lkundrak@v3.sk>
Cc: util-linux@vger.kernel.org, Mikhail Gusarov <dottedmag@dottedmag.net>
Subject: Re: [PATCH 2/2] unshare: allow persisting namespaces
Date: Sun, 15 Feb 2015 07:10:45 -0500	[thread overview]
Message-ID: <20150215121045.GA3910@vapier> (raw)
In-Reply-To: <1419798218-3174-2-git-send-email-lkundrak@v3.sk>

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

On 28 Dec 2014 21:23, Lubomir Rintel wrote:
> Bind mount the namespace file to a given location after creating it if
> requested (analogously to what "ip netns" and other tools do).

since i found out about `ip netns`, i've wanted this in unshare ;).  although 
the two implementations seem to differ: iproute uses a common location 
(/run/netns/$NAME) while this implementation requires specifying the full path 
all the time.  would it be possible to rectify this ?

maybe if you give it a plain name, it defaults to a common location ?  so 
something like this would "just work":
  $ ip netns add foo
  $ unshare --net=foo ...
(yes, i'm aware of `ip netns exec ...`)

using /run/${type}ns/ for all paths seems a bit ugly ... maybe claim 
/run/ns/${type}/ instead ?

> The ugly bit about this patch is the clone(2) call, arguably not our
> fault. The stack size glibc requires for its clone(2) wrapper is not
> documented anywhere and its semantics (stack growth direction) is arch
> dependent. We could figure it out by comparing a return value of a helper
> function that would return an address of its local variable with caller's
> local variable address, but I guess that would be even more messed-up.

are you sure this is strictly a glibc requirement ?  seems like it's mostly 
hardware/ABI related (certainly direction is).  i'd also point out that ia64 
doesn't implement clone either ... it has __clone2().

> +static struct namespace_file {

const

> +	int nstype;
> +	const char *proc_name;
> +	const char *target_name;
> +} namespace_files[] = {
> +	{ .nstype = CLONE_NEWUSER, .proc_name = "ns/user", .target_name = NULL },
> +	{ .nstype = CLONE_NEWIPC,  .proc_name = "ns/ipc",  .target_name = NULL },
> +	{ .nstype = CLONE_NEWUTS,  .proc_name = "ns/uts",  .target_name = NULL },
> +	{ .nstype = CLONE_NEWNET,  .proc_name = "ns/net",  .target_name = NULL },
> +	{ .nstype = CLONE_NEWPID,  .proc_name = "ns/pid",  .target_name = NULL },
> +	{ .nstype = CLONE_NEWNS,   .proc_name = "ns/mnt",  .target_name = NULL },
> +	{ .nstype = 0, .proc_name = NULL, .target_name = NULL }

use ARRAY_SIZE instead and you don't need the sentinel entry

> +int c, forkit = 0, maproot = 0;
> +const char *procmnt = NULL;

static

> +	fputs(_(" -m, --mount[=<file>]      unshare mounts namespace\n"), out);
> +	fputs(_(" -u, --uts[=<file>]        unshare UTS namespace (hostname etc)\n"), out);
> +	fputs(_(" -i, --ipc[=<file>]        unshare System V IPC namespace\n"), out);
> +	fputs(_(" -n, --net[=<file>]        unshare network namespace\n"), out);
> +	fputs(_(" -p, --pid[=<file>]        unshare pid namespace\n"), out);
> +	fputs(_(" -U, --user[=<file>]       unshare user namespace\n"), out);

probably want <path> instead of <file> since it can be either

> +static void persist_ns(pid_t pid)
> +{
> +	struct namespace_file *nsfile;
> +
> +	for (nsfile = namespace_files; nsfile->nstype; nsfile++) {
> +		char pathbuf[PATH_MAX];
> +
> +		if (!nsfile->target_name)
> +			continue;
> +
> +		snprintf(pathbuf, sizeof(pathbuf), "/proc/%u/%s", pid,
> +			nsfile->proc_name);

use xasprintf to avoid the PATH_MAX constant

> +		if (-1 == mknod(nsfile->target_name, 0666, 0)) {
> +			warn(_("failed to create %s"), nsfile->target_name);
> +			continue;
> +		}
> +
> +		if (-1 == mount(pathbuf, nsfile->target_name, NULL, MS_BIND, NULL)) {
> +			warn(_("mount %s failed"), nsfile->target_name);
> +			unlink(nsfile->target_name);

generally the codebase uses the other style -- constants go on the right

> +static int in_child (void *arg)

no space before the (
-mike

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

  parent reply	other threads:[~2015-02-15 12:08 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-28 20:23 [PATCH 1/2] unshare: add some examples Lubomir Rintel
2014-12-28 20:23 ` [PATCH 2/2] unshare: allow persisting namespaces Lubomir Rintel
2015-01-06 13:03   ` Karel Zak
2015-01-06 17:11     ` Eric W. Biederman
2015-01-06 17:21       ` Karel Zak
2015-01-06 17:44         ` Eric W. Biederman
2015-02-15 12:10   ` Mike Frysinger [this message]
2015-01-12 11:41 ` [PATCH 1/2] unshare: add some examples Karel Zak

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150215121045.GA3910@vapier \
    --to=vapier@gentoo.org \
    --cc=dottedmag@dottedmag.net \
    --cc=lkundrak@v3.sk \
    --cc=util-linux@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.