From: Mike Frysinger <vapier@gentoo.org>
To: Karel Zak <kzak@redhat.com>
Cc: util-linux@vger.kernel.org, ebiederm@xmission.com,
mtk.manpages@gmail.com
Subject: Re: [PATCH/RFC] unshare: add --fork/--mount-proc options for pid namespaces
Date: Wed, 3 Jul 2013 13:08:30 -0400 [thread overview]
Message-ID: <201307031308.31557.vapier@gentoo.org> (raw)
In-Reply-To: <20130703103635.GA722@x2.net.home>
[-- Attachment #1: Type: Text/Plain, Size: 2122 bytes --]
On Wednesday 03 July 2013 06:36:35 Karel Zak wrote:
> On Mon, Jul 01, 2013 at 10:47:04AM -0400, Mike Frysinger wrote:
> > On Monday 01 July 2013 07:40:08 Karel Zak wrote:
> > > On Thu, Jun 27, 2013 at 08:04:58PM -0400, Mike Frysinger wrote:
> > > > When it comes to pid namespaces, it's also useful for /proc to
> > > > reflect the current namespace. Again, this is easy to pull off, but
> > > > annoying to force everyone to do it themselves. So let's add a
> > > > --mount-proc to do the magic for us.
> > >
> > > This is not so easy. For example on Fedora 18 the default is "shared":
> > >
> > > # grep /proc /proc/self/mountinfo
> > > 14 33 0:3 / /proc rw,nosuid,nodev,noexec,relatime shared:5 - proc proc
> > > rw
> > >
> > > it means that unshare( CLONE_NEWNS ) has no expected effect and the
> > > following mount(/proc) has horrible impact for all system. You have
> > >
> > > to use (for example):
> > > mount --make-rprivate /proc
> > > unshare --fork --mount-proc --pid
> >
> > i'm not quite following here. are you saying that Fedora 18 by default
> > makes it hard to do pid namespaces ?
>
> /proc does not have to be private. You have to call
>
> mount("none", "/proc", NULL, MS_PRIVATE|MS_REC, NULL);
>
> to be sure that unshare(CLONE_NEWNS) makes any effect. It's mistake
> to blindly call
>
> unshare( CLONE_NEWNS );
> mount("proc, "/proc", "proc", 0, NULL);
>
> If we want to add --mount-proc to unshare(1) than the implementation has
> to be robust. Your current patch is dangerous on systems where /proc is
> shared.
well, it usually does more:
unshare(...);
fork();
mount(...);
but if just adding MS_PRIVATE makes it work w/out needing to do
unshare(NEWNS), that's even better. i'm not familiar with that flag as it's
not in the mount(2) man page (looks like it's listed as a TODO).
> It would be also nice to support optional argument to specify the
> mountpoint --mount-proc[=<mountpoint>].
>
> See the patch below -- works for me.
Acked-by: Mike Frysinger <vapier@gentoo.or>
-mike
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
next prev parent reply other threads:[~2013-07-03 17:08 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-28 0:04 [PATCH/RFC] unshare: add --fork/--mount-proc options for pid namespaces Mike Frysinger
2013-07-01 11:40 ` Karel Zak
2013-07-01 14:47 ` Mike Frysinger
2013-07-03 10:36 ` Karel Zak
2013-07-03 17:08 ` Mike Frysinger [this message]
2013-07-09 9:08 ` 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=201307031308.31557.vapier@gentoo.org \
--to=vapier@gentoo.org \
--cc=ebiederm@xmission.com \
--cc=kzak@redhat.com \
--cc=mtk.manpages@gmail.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox