From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>,
Andrew Vagin <avagin@virtuozzo.com>
Cc: Linux API <linux-api@vger.kernel.org>,
Containers <containers@lists.linux-foundation.org>,
lkml <linux-kernel@vger.kernel.org>,
criu@openvz.org,
"Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com>
Subject: Re: [CRIU] Introspecting userns relationships to other namespaces?
Date: Fri, 08 Jul 2016 07:35:33 -0700 [thread overview]
Message-ID: <1467988533.2322.118.camel@HansenPartnership.com> (raw)
In-Reply-To: <87vb0gy3nr.fsf@x220.int.ebiederm.org>
On Fri, 2016-07-08 at 02:44 -0500, Eric W. Biederman wrote:
> Andrew Vagin <avagin@virtuozzo.com> writes:
>
> > On Wed, Jul 06, 2016 at 10:46:33AM -0500, Eric W. Biederman wrote:
> > > "Serge E. Hallyn" <serge@hallyn.com> writes:
> > >
> > > > On Wed, Jul 06, 2016 at 10:41:48AM +0200, Michael Kerrisk (man
> > > > -pages) wrote:
> > > > > [Rats! Doing now what I should have down to start with.
> > > > > Looping some
> > > > > lists and CRIU and other possibly relevant people into this
> > > > > conversation]
> > > > >
> > > > > Hi Eric,
> > > > >
> > > > > On 5 July 2016 at 23:47, Eric W. Biederman <
> > > > > ebiederm@xmission.com> wrote:
> > > > > > "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com>
> > > > > > writes:
> > > > > >
> > > > > > > Hi Eric,
> > > > > > >
> > > > > > > I have a question. Is there any way currently to discover
> > > > > > > which user namespace a particular nonuser namespace is
> > > > > > > governed by? Maybe I am missing something, but there does
> > > > > > > not seem to be a way to do this. Also, can one discover
> > > > > > > which userns is the parent of a given userns? Again, I
> > > > > > > can't see a way to do this.
> > > > > > >
> > > > > > > The point here is introspecting so that a process might
> > > > > > > determine what its capabilities are when operating on
> > > > > > > some resource governed by a (nonuser) namespace.
> > > > > >
> > > > > > To the best of my knowledge that there is not an interface
> > > > > > to get that information. It would be good to have such an
> > > > > > interface for no other reason than the CRIU folks are going
> > > > > > to need it at some point. I am a bit surprised they have
> > > > > > not complained yet.
> > > >
> > > > I don't think they need it. They do in fact have what they
> > > > need. Assume you have tasks T1, T2, T1_1 and T2_1; T1 and T2
> > > > are in init_user_ns; T1 spawned T1_1 in a new userns; T2
> > > > spawned T2_1 which setns()d to T1_1's ns. There's some
> > > > {handwave} uid mapping, does not matter.
> > > >
> > > > At restart, it doesn't matter which task originally created the
> > > > new userns. criu knows T1_1 and T2_1 are in the same userns;
> > > > it creates the userns, sets up the mapping, and T1_1 and T2_1
> > > > setns() to it.
> > >
> > > Given that the simple cases are so easy it probably doesn't
> > > matter in that sense.
> > >
> > > However we now have the case where user namespaces own pid
> > > namespaces, and uts namespaces, and network namespaces, and ipc
> > > namespaces, and filesystems. Throw in some mount propagation and
> > > use of setns and things could get confusing. It is something
> > > that will need to be figured out if CRIU is going to properly
> > > checkpoint containers containing containers containing containers
> > > containing containers.
> >
> > It isn't a joke:). We have a few requests to support CR of
> > containers with Docker containers inside. And we are going to start
> > this task in a near future, so we would like to have interface to
> > get dependencies between namespaces too.
> >
> > BTW: CRIU already supports nested mount namespaces, because systemd
> > creates them for services.
>
> The tricky part about this and what messes up James proposed plan is
> that the interface needs to be something that returns a namespace
> file descriptor. So we can't print something out in a simple text
> file.
I actually described two problems: the first was how we get the
information in the first place. Currently the owning or parent user_ns
is tucked inside an opaque structure. I think we need to move that to
ns_common where it would be the owning userns for all non-user
namespaces and the parent for the userns.
Once we actually have the information, we can also add a set of proc
links, say either
/proc/<pid>/ns/X-userns
Which might be a bit messy since it doubles the number of files, or
perhaps in a simple directory.
> Well I suppose we could print an device number and inode number pair.
> But then someone would still have to scour processes looking for a
> user namespace so that is likely less than ideal.
There's no reason any of the proposed methods so far have to be
exclusive: nsfs.c has a lot of flexibility.
> Starting with 4.8 we are also going to need to be able to retrieve
> the user namespace owner of filesystems. That will be an interesting
> mix.
This is per mount point, isn't it? so it can't be in /proc/fs/ and it
would have to be per local mount tree. Yes, that is a bit nasty.
Sounds like we might need to unfold mount or mountinfo into something
that has one directory per entry?
James
> Eric
>
> _______________________________________________
> Containers mailing list
> Containers@lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/containers
>
next prev parent reply other threads:[~2016-07-08 14:37 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <c2a26220-69f2-f2f5-491a-e43abd9a6f92@gmail.com>
[not found] ` <87r3b7pxja.fsf@x220.int.ebiederm.org>
2016-07-06 8:41 ` Introspecting userns relationships to other namespaces? Michael Kerrisk (man-pages)
2016-07-06 14:13 ` Serge E. Hallyn
2016-07-06 15:46 ` Eric W. Biederman
2016-07-08 1:57 ` [CRIU] " Andrew Vagin
2016-07-08 7:44 ` Eric W. Biederman
2016-07-08 14:35 ` James Bottomley [this message]
2016-07-08 20:38 ` Andrew Vagin
2016-07-08 20:50 ` W. Trevor King
2016-07-08 22:19 ` James Bottomley
2016-07-08 22:19 ` James Bottomley
2016-07-08 23:52 ` Eric W. Biederman
2016-07-09 0:15 ` James Bottomley
2016-07-09 3:05 ` Eric W. Biederman
2016-07-09 7:26 ` Andrew Vagin
2016-07-09 10:31 ` James Bottomley
2016-07-09 10:32 ` James Bottomley
2016-07-09 18:15 ` Eric W. Biederman
2016-07-09 18:29 ` Eric W. Biederman
2016-07-13 0:08 ` Andrew Vagin
2016-07-13 3:59 ` W. Trevor King
2016-07-07 8:15 ` Michael Kerrisk (man-pages)
2016-07-07 13:36 ` Serge E. Hallyn
2016-07-07 15:01 ` James Bottomley
2016-07-07 18:21 ` Michael Kerrisk (man-pages)
2016-07-07 18:24 ` Serge E. Hallyn
2016-07-07 19:17 ` James Bottomley
2016-07-08 2:16 ` [CRIU] " Andrew Vagin
2016-07-08 3:00 ` Andrew Vagin
2016-07-08 3:26 ` James Bottomley
2016-07-08 5:26 ` W. Trevor King
2016-07-08 6:16 ` W. Trevor King
2016-07-08 6:54 ` Andrew Vagin
2016-07-08 7:18 ` W. Trevor King
2016-07-08 5:41 ` [CRIU] " Andrei Vagin
2016-07-08 5:47 ` Andrei Vagin
2016-07-08 6:07 ` James Bottomley
2016-07-08 11:17 ` Michael Kerrisk (man-pages)
2016-07-08 3:20 ` James Bottomley
2016-07-08 6:09 ` Andrew Vagin
2016-07-08 11:11 ` Michael Kerrisk (man-pages)
2016-07-09 3:15 ` W. Trevor King
2016-07-09 3:13 ` Eric W. Biederman
2016-07-10 5:36 ` [CRIU] " Andrew Vagin
2016-07-10 20:29 ` Eric W. Biederman
2016-07-10 21:06 ` James Bottomley
2016-07-11 20:55 ` Andrew Vagin
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=1467988533.2322.118.camel@HansenPartnership.com \
--to=james.bottomley@hansenpartnership.com \
--cc=avagin@virtuozzo.com \
--cc=containers@lists.linux-foundation.org \
--cc=criu@openvz.org \
--cc=ebiederm@xmission.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mtk.manpages@gmail.com \
/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;
as well as URLs for NNTP newsgroup(s).