Re: Introspecting userns relationships to other namespaces?

Quoting Michael Kerrisk (man-pages) (mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org):

Hi Serge,

On 6 July 2016 at 16:13, Serge E. Hallyn [off-list ref] wrote:

quoted

On Wed, Jul 06, 2016 at 10:41:48AM +0200, Michael Kerrisk (man-pages) wrote:

quoted

[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 [off-list ref] wrote:

quoted

"Michael Kerrisk (man-pages)" [off-list ref] writes:

quoted

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.

I'm missing something here. How does the parental relationships
between the user namespaces get reconstructed? Those relationships
will govern what capabilities a process will have in various user
namespaces.

Hm.  Probably best-effort based on the process hierarchy.  So yeah you
could probably get a tree into a state that would be wrongly recreated.
Create a new netns, bind mount it, exit;  Have another task create a
new user_ns, bind mount it, exit;  Third task setns()s first to the new
netns then to the new user_ns.  I suspect criu will recreate that
wrongly.