On Fri, 2016-07-08 at 02:44 -0500, Eric W. Biederman wrote:
> Andrew Vagin <avagin@xxxxxxxxxxxxx> writes:
>
> > On Wed, Jul 06, 2016 at 10:46:33AM -0500, Eric W. Biederman wrote:
> > > "Serge E. Hallyn" <serge@xxxxxxxxxx> 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@xxxxxxxxxxxx> wrote:
> > > > > > "Michael Kerrisk (man-pages)" <mtk.manpages@xxxxxxxxx>
> > > > > > 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@xxxxxxxxxxxxxxxxxxxxxxxxxx
> https://lists.linuxfoundation.org/mailman/listinfo/containers
>
--
To unsubscribe from this list: send the line "unsubscribe linux-api" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
