From: Michael Kerrisk (man-pages) <hidden> Date: 2016-07-06 08:42:18
[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:
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.
That said in a normal use scenario I don't think that information is
needed.
Do you have a particular use case besides checkpoint/restart where this
is useful? That might help in coming up with a good userspace interface
for this information.
So, I spend a moderate amount of time working with people to introduce
them to the namespaces infrastructure, and one topic that comes up now
and this introspection/visualization tools. For example,
nowadays--thanks to the (bizarrely misnamed) NStgid and NSpid fields
in /proc/PID--it's possible to (and someone I was working with did)
write tools that introspect the PID namespace hierarchy to show all of
process's and their PIDs in the various namespace instance. It's a
natural enough thing to want to do, when confronted with the
complexity of the namespaces.
Someone else then asked me a question that led me to wonder about
generally introspecting on the parental relationships between user
namespaces and the association of other namespaces types with user
namespaces. One use would be visualization, in order to understand the
running system. Another would be to answer the question I already
mentioned: what capability does process X have to perform operations
on a resource governed by namespace Y?
Cheers,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
From: "Serge E. Hallyn" <serge@hallyn.com> Date: 2016-07-06 14:13:54
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 [off-list ref] wrote:
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.
quoted
That said in a normal use scenario I don't think that information is
needed.
Do you have a particular use case besides checkpoint/restart where this
is useful? That might help in coming up with a good userspace interface
for this information.
So, I spend a moderate amount of time working with people to introduce
them to the namespaces infrastructure, and one topic that comes up now
and this introspection/visualization tools. For example,
nowadays--thanks to the (bizarrely misnamed) NStgid and NSpid fields
in /proc/PID--it's possible to (and someone I was working with did)
write tools that introspect the PID namespace hierarchy to show all of
process's and their PIDs in the various namespace instance. It's a
natural enough thing to want to do, when confronted with the
complexity of the namespaces.
Someone else then asked me a question that led me to wonder about
generally introspecting on the parental relationships between user
namespaces and the association of other namespaces types with user
namespaces. One use would be visualization, in order to understand the
running system. Another would be to answer the question I already
mentioned: what capability does process X have to perform operations
on a resource governed by namespace Y?
I agree they'll probably want it, but if we want for a real need and
use case we can do a better job of providing what's needed.
-serge
From: Michael Kerrisk (man-pages) <hidden> Date: 2016-07-07 08:16:18
Hi Serge,
On 6 July 2016 at 16:13, Serge E. Hallyn [off-list ref] wrote:
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:
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.
Cheers,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
From: "Serge E. Hallyn" <serge@hallyn.com> Date: 2016-07-07 13:37:09
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:
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.
From: James Bottomley <James.Bottomley@HansenPartnership.com> Date: 2016-07-07 15:02:06
On Thu, 2016-07-07 at 08:36 -0500, Serge E. Hallyn wrote:
Quoting Michael Kerrisk (man-pages) (mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org):
quoted
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 <
ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org> wrote:
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.
Actually, you get the parent namespace from the process tree by
tracking the user namespaces of the parent pids. Currently non-root
users can't bind the namespace, so the only way to keep a new user_ns
around if you're not root is to keep the process around, so for
multiply nested user namespaces you can usually build the user_ns
hierarchy by looking at the process hierarchy. Conversely, if the
process is reparented to init, chances are that the user_ns is also
parented to init_user_ns.
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.
This is a bit pathological, and you have to be root to do it: so root
can set up a nesting hierarchy, bind it and destroy the pids but I know
of no current orchestration system which does this.
Actually, I have to back pedal a bit: the way I currently set up
architecture emulation containers does precisely this: I set up the
namespaces unprivileged with child mount namespaces, but then I ask
root to bind the userns and kill the process that created it so I have
a permanent handle to enter the namespace by, so I suspect that when
our current orchestration systems get more sophisticated, they might
eventually want to do something like this as well.
In theory, we could get nsfs to show this information as an option
(just add a show_options entry to the superblock ops), but the problem
is that although each namespace has a parent user_ns, there's no way to
get it without digging in the namespace specific structure. Probably
we should restructure to move it into ns_common, then we could display
it (and enforce all namespaces having owning user_ns) but it would be a
reasonably large (but mechanical) change.
James
From: Michael Kerrisk (man-pages) <hidden> Date: 2016-07-07 18:22:07
On 7 July 2016 at 17:01, James Bottomley
[off-list ref] wrote:
On Thu, 2016-07-07 at 08:36 -0500, Serge E. Hallyn wrote:
quoted
Quoting Michael Kerrisk (man-pages) (mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org):
quoted
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 <
ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org> wrote:
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.
Actually, you get the parent namespace from the process tree by
tracking the user namespaces of the parent pids. Currently non-root
users can't bind the namespace, so the only way to keep a new user_ns
around if you're not root is to keep the process around, so for
multiply nested user namespaces you can usually build the user_ns
hierarchy by looking at the process hierarchy. Conversely, if the
process is reparented to init, chances are that the user_ns is also
parented to init_user_ns.
Yes, but "chances are" == this isn't robust. PR_SET_CHILD_SUBREAPER
further complicates things.
By the way, is that really what happens? Do child user namespaces get
reparented to the grandparent ns if the parent ns disappears (i.e.,
ceases to have any members and no bind mounts)? I hadn't thought about
that scenario before. It may be worth documenting in
user_namespaces(7).
quoted
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.
This is a bit pathological, and you have to be root to do it: so root
can set up a nesting hierarchy, bind it and destroy the pids but I know
of no current orchestration system which does this.
Actually, I have to back pedal a bit: the way I currently set up
architecture emulation containers does precisely this: I set up the
namespaces unprivileged with child mount namespaces, but then I ask
root to bind the userns and kill the process that created it so I have
a permanent handle to enter the namespace by, so I suspect that when
our current orchestration systems get more sophisticated, they might
eventually want to do something like this as well.
In theory, we could get nsfs to show this information as an option
(just add a show_options entry to the superblock ops), but the problem
is that although each namespace has a parent user_ns, there's no way to
get it without digging in the namespace specific structure. Probably
we should restructure to move it into ns_common, then we could display
it (and enforce all namespaces having owning user_ns) but it would be a
I'm missing something here. Is it not already the case that all
namespaces have an owning user_ns?
Cheers,
Michael
From: "Serge E. Hallyn" <serge@hallyn.com> Date: 2016-07-07 18:24:47
Quoting Michael Kerrisk (man-pages) (mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org):
On 7 July 2016 at 17:01, James Bottomley
[off-list ref] wrote:
quoted
On Thu, 2016-07-07 at 08:36 -0500, Serge E. Hallyn wrote:
quoted
Quoting Michael Kerrisk (man-pages) (mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org):
quoted
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 <
ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org> wrote:
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.
Actually, you get the parent namespace from the process tree by
tracking the user namespaces of the parent pids. Currently non-root
users can't bind the namespace, so the only way to keep a new user_ns
around if you're not root is to keep the process around, so for
multiply nested user namespaces you can usually build the user_ns
hierarchy by looking at the process hierarchy. Conversely, if the
process is reparented to init, chances are that the user_ns is also
parented to init_user_ns.
Yes, but "chances are" == this isn't robust. PR_SET_CHILD_SUBREAPER
further complicates things.
By the way, is that really what happens? Do child user namespaces get
reparented to the grandparent ns if the parent ns disappears (i.e.,
The parent ns cannot disappear. The child ns pins the creator's cred,
which pins the parent user_ns.
From: James Bottomley <James.Bottomley@HansenPartnership.com> Date: 2016-07-07 19:17:47
On Thu, 2016-07-07 at 20:21 +0200, Michael Kerrisk (man-pages) wrote:
On 7 July 2016 at 17:01, James Bottomley
[off-list ref] wrote:
[Serge already answered the parenting issue]
quoted
On Thu, 2016-07-07 at 08:36 -0500, Serge E. Hallyn wrote:
quoted
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.
This is a bit pathological, and you have to be root to do it: so
root can set up a nesting hierarchy, bind it and destroy the pids
but I know of no current orchestration system which does this.
Actually, I have to back pedal a bit: the way I currently set up
architecture emulation containers does precisely this: I set up the
namespaces unprivileged with child mount namespaces, but then I ask
root to bind the userns and kill the process that created it so I
have a permanent handle to enter the namespace by, so I suspect
that when our current orchestration systems get more sophisticated,
they might eventually want to do something like this as well.
In theory, we could get nsfs to show this information as an option
(just add a show_options entry to the superblock ops), but the
problem is that although each namespace has a parent user_ns,
there's no way to get it without digging in the namespace specific
structure. Probably we should restructure to move it into
ns_common, then we could display it (and enforce all namespaces
having owning user_ns) but it would be a
I'm missing something here. Is it not already the case that all
namespaces have an owning user_ns?
Um, yes, I don't believe I said they don't. The problem I thought you
were having is that there's no way of seeing what it is.
nsfs is the Namespace fileystem where bound namespaces appear to a cat
of /proc/self/mounts. It can display any information that's in
ns_common (the common core of namespaces) but the owning user_ns
pointer currently isn't in this structure. Every user namespace has a
pointer to it, but they're all privately embedded in the individual
namespace specific structures. What I was proposing was that since
every current namespace has a pointer somewhere to the owning user
namespace, we could abstract this out into ns_common so it's now
accessible to be displayed by nsfs, probably as a mount option.
James
From: James Bottomley <James.Bottomley@HansenPartnership.com> Date: 2016-07-08 03:20:20
On Thu, 2016-07-07 at 19:16 -0700, Andrew Vagin wrote:
On Thu, Jul 07, 2016 at 12:17:35PM -0700, James Bottomley wrote:
quoted
On Thu, 2016-07-07 at 20:21 +0200, Michael Kerrisk (man-pages)
wrote:
quoted
On 7 July 2016 at 17:01, James Bottomley
[off-list ref] wrote:
[Serge already answered the parenting issue]
quoted
quoted
On Thu, 2016-07-07 at 08:36 -0500, Serge E. Hallyn wrote:
quoted
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.
This is a bit pathological, and you have to be root to do it:
so
root can set up a nesting hierarchy, bind it and destroy the
pids
but I know of no current orchestration system which does this.
Actually, I have to back pedal a bit: the way I currently set
up
architecture emulation containers does precisely this: I set up
the
namespaces unprivileged with child mount namespaces, but then I
ask
root to bind the userns and kill the process that created it so
I
have a permanent handle to enter the namespace by, so I suspect
that when our current orchestration systems get more
sophisticated,
they might eventually want to do something like this as well.
In theory, we could get nsfs to show this information as an
option
(just add a show_options entry to the superblock ops), but the
problem is that although each namespace has a parent user_ns,
there's no way to get it without digging in the namespace
specific
structure. Probably we should restructure to move it into
ns_common, then we could display it (and enforce all namespaces
having owning user_ns) but it would be a
I'm missing something here. Is it not already the case that all
namespaces have an owning user_ns?
Um, yes, I don't believe I said they don't. The problem I thought
you
were having is that there's no way of seeing what it is.
nsfs is the Namespace fileystem where bound namespaces appear to a
cat
of /proc/self/mounts. It can display any information that's in
ns_common (the common core of namespaces) but the owning user_ns
pointer currently isn't in this structure. Every user namespace
has a
pointer to it, but they're all privately embedded in the individual
namespace specific structures. What I was proposing was that since
every current namespace has a pointer somewhere to the owning user
namespace, we could abstract this out into ns_common so it's now
accessible to be displayed by nsfs, probably as a mount option.
James, I am not sure that I understood you correctly. We have one
file system for all namespace files, how we can show per-file
properties in mount options.
We have two ways of getting information. For a namespace that only
exists as a bind mount we only have what the mount/mountinfo shows, so
you see something like this:
jejb@jarvis:~> mount|grep nsfs
nsfs on /run/build-container/userns type nsfs (rw)
nsfs on /run/build-container/ppc64 type nsfs (rw)
the (rw) are the mount options. We could add the ability to add other
mount options to this via the superblock .show_options callback. We
could make it show the type and parent user namespace.
I think we can show all required information in fdinfo. We open a
namespaces file (/proc/pid/ns/N) and then read /proc/pid/fdinfo/X for
it.
Not if we don't have an extant process in the namespace, we can't use
these files because they don't exist, plus fdinfo on the
/proc/<pid>/ns/X doesn't tell you what the parent user_ns of X is
(again, we could add this information somewhere ... not sure where
yet).
James
From: James Bottomley <James.Bottomley@HansenPartnership.com> Date: 2016-07-08 03:26:51
On Thu, 2016-07-07 at 20:00 -0700, Andrew Vagin wrote:
On Thu, Jul 07, 2016 at 07:16:18PM -0700, Andrew Vagin wrote:
quoted
On Thu, Jul 07, 2016 at 12:17:35PM -0700, James Bottomley wrote:
quoted
On Thu, 2016-07-07 at 20:21 +0200, Michael Kerrisk (man-pages)
wrote:
quoted
On 7 July 2016 at 17:01, James Bottomley
[off-list ref] wrote:
[Serge already answered the parenting issue]
quoted
quoted
On Thu, 2016-07-07 at 08:36 -0500, Serge E. Hallyn wrote:
quoted
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.
This is a bit pathological, and you have to be root to do it:
so
root can set up a nesting hierarchy, bind it and destroy the
pids
but I know of no current orchestration system which does
this.
Actually, I have to back pedal a bit: the way I currently set
up
architecture emulation containers does precisely this: I set
up the
namespaces unprivileged with child mount namespaces, but then
I ask
root to bind the userns and kill the process that created it
so I
have a permanent handle to enter the namespace by, so I
suspect
that when our current orchestration systems get more
sophisticated,
they might eventually want to do something like this as well.
In theory, we could get nsfs to show this information as an
option
(just add a show_options entry to the superblock ops), but
the
problem is that although each namespace has a parent user_ns,
there's no way to get it without digging in the namespace
specific
structure. Probably we should restructure to move it into
ns_common, then we could display it (and enforce all
namespaces
having owning user_ns) but it would be a
I'm missing something here. Is it not already the case that all
namespaces have an owning user_ns?
Um, yes, I don't believe I said they don't. The problem I
thought you
were having is that there's no way of seeing what it is.
nsfs is the Namespace fileystem where bound namespaces appear to
a cat
of /proc/self/mounts. It can display any information that's in
ns_common (the common core of namespaces) but the owning user_ns
pointer currently isn't in this structure. Every user namespace
has a
pointer to it, but they're all privately embedded in the
individual
namespace specific structures. What I was proposing was that
since
every current namespace has a pointer somewhere to the owning
user
namespace, we could abstract this out into ns_common so it's now
accessible to be displayed by nsfs, probably as a mount option.
James, I am not sure that I understood you correctly. We have one
file system for all namespace files, how we can show per-file
properties
in mount options. I think we can show all required information in
fdinfo. We open a namespaces file (/proc/pid/ns/N) and then read
/proc/pid/fdinfo/X for it.
Here is a proof-of-concept patch.
How it works:
In [1]: import os
In [2]: fd = os.open("/proc/self/ns/pid", os.O_RDONLY)
In [3]: print open("/proc/self/fdinfo/%d" % fd).read()
pos: 0
flags: 0100000
mnt_id: 2
userns: 4026531837
In [4]: print "/proc/self/ns/user -> %s" %
os.readlink("/proc/self/ns/user")
/proc/self/ns/user -> user:[4026531837]
can't you just do
readlink /proc/self/ns/user | sed 's/.*\[\(.*\)\]/\1/'
?
But what Michael was asking about was the parent user_ns of all the
other namespaces ... I don't think there's any way we can get that out
of any information in /proc/self/
James
From: Andrew Vagin <hidden> Date: 2016-07-08 03:36:35
On Thu, Jul 07, 2016 at 07:16:18PM -0700, Andrew Vagin wrote:
On Thu, Jul 07, 2016 at 12:17:35PM -0700, James Bottomley wrote:
quoted
On Thu, 2016-07-07 at 20:21 +0200, Michael Kerrisk (man-pages) wrote:
quoted
On 7 July 2016 at 17:01, James Bottomley
[off-list ref] wrote:
[Serge already answered the parenting issue]
quoted
quoted
On Thu, 2016-07-07 at 08:36 -0500, Serge E. Hallyn wrote:
quoted
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.
This is a bit pathological, and you have to be root to do it: so
root can set up a nesting hierarchy, bind it and destroy the pids
but I know of no current orchestration system which does this.
Actually, I have to back pedal a bit: the way I currently set up
architecture emulation containers does precisely this: I set up the
namespaces unprivileged with child mount namespaces, but then I ask
root to bind the userns and kill the process that created it so I
have a permanent handle to enter the namespace by, so I suspect
that when our current orchestration systems get more sophisticated,
they might eventually want to do something like this as well.
In theory, we could get nsfs to show this information as an option
(just add a show_options entry to the superblock ops), but the
problem is that although each namespace has a parent user_ns,
there's no way to get it without digging in the namespace specific
structure. Probably we should restructure to move it into
ns_common, then we could display it (and enforce all namespaces
having owning user_ns) but it would be a
I'm missing something here. Is it not already the case that all
namespaces have an owning user_ns?
Um, yes, I don't believe I said they don't. The problem I thought you
were having is that there's no way of seeing what it is.
nsfs is the Namespace fileystem where bound namespaces appear to a cat
of /proc/self/mounts. It can display any information that's in
ns_common (the common core of namespaces) but the owning user_ns
pointer currently isn't in this structure. Every user namespace has a
pointer to it, but they're all privately embedded in the individual
namespace specific structures. What I was proposing was that since
every current namespace has a pointer somewhere to the owning user
namespace, we could abstract this out into ns_common so it's now
accessible to be displayed by nsfs, probably as a mount option.
James, I am not sure that I understood you correctly. We have one
file system for all namespace files, how we can show per-file properties
in mount options. I think we can show all required information in
fdinfo. We open a namespaces file (/proc/pid/ns/N) and then read
/proc/pid/fdinfo/X for it.
Here is a proof-of-concept patch.
How it works:
In [1]: import os
In [2]: fd = os.open("/proc/self/ns/pid", os.O_RDONLY)
In [3]: print open("/proc/self/fdinfo/%d" % fd).read()
pos: 0
flags: 0100000
mnt_id: 2
userns: 4026531837
In [4]: print "/proc/self/ns/user -> %s" % os.readlink("/proc/self/ns/user")
/proc/self/ns/user -> user:[4026531837]
From: W. Trevor King <hidden> Date: 2016-07-08 05:32:02
On Thu, Jul 07, 2016 at 08:26:47PM -0700, James Bottomley wrote:
On Thu, 2016-07-07 at 20:00 -0700, Andrew Vagin wrote:
quoted
On Thu, Jul 07, 2016 at 07:16:18PM -0700, Andrew Vagin wrote:
quoted
I think we can show all required information in fdinfo. We open
a namespaces file (/proc/pid/ns/N) and then read
/proc/pid/fdinfo/X for it.
Here is a proof-of-concept patch.
…
In [2]: fd = os.open("/proc/self/ns/pid", os.O_RDONLY)
In [3]: print open("/proc/self/fdinfo/%d" % fd).read()
pos: 0
flags: 0100000
mnt_id: 2
userns: 4026531837
In [4]: print "/proc/self/ns/user -> %s" %
os.readlink("/proc/self/ns/user")
/proc/self/ns/user -> user:[4026531837]
can't you just do
readlink /proc/self/ns/user | sed 's/.*\[\(.*\)\]/\1/'
With Andrew's fdinfo approach you know the user namespace owning
/proc/self/ns/pid is 4026531837. That happens to be
/proc/self/ns/user in this case, but doesn't have to be in general.
But what Michael was asking about was the parent user_ns of all the
other namespaces ... I don't think there's any way we can get that
out of any information in /proc/self/
If fdinfo only shows immediate parents, you'd need to walk the tree to
get back to the root. And at each layer of the PID namespace tree
there will be another user-namespace parent branching off). With a
tree like:
Namespace | Parent | Owning userns
-------------------+--------------+-------------------
Root userns | - | -
Root PID ns | - | Root userns
Child userns | Root usens | Root userns
Child PID ns | Root PID ns | Root userns
Grandchild userns | Child userns | Child userns
Grandchild PID ns | Child PID ns | Grandchild userns
Walking from the granchild PID namespace would give you:
Grandchild PID ns
|-- Child PID ns
| |-- Root PID ns
| `-- Root userns
`-- Granchild userns
`-- Child userns
`-- Root userns
If you only put one level in fdinfo, you're stuck if one of the
namespaces involved has neither bind mounts nor a PID to give you
handle on it [1]. And if you want to put that whole ancestor tree in
fdinfo, you have to come up with some way to handle the two-parent
branching.
I'm also not sure how exposing nsfs information [2] would handle
namespaces that had neither a surviving bind mount nor a direct
process.
If all the information is available (possible after a mechanical patch
[3] makes it more accessible), then it seems easier to put it in a
separate /proc or /sys file. There was a stab at this for PID
namespaces in [4] (the same series that landed NStgid, etc.) with
additional background and alternative approaches in [5]. There were
problems with that patch (and it was trying to do more by also listing
a process's ID in each PID namespace), but the “let's put the whole
tree in a new file” approach seems sound to me.
Cheers,
Trevor
[1]: http://thread.gmane.org/gmane.linux.kernel.containers/30456/focus=20536
Subject: Re: Introspecting userns relationships to other namespaces?
Date: Thu, 7 Jul 2016 13:24:42 -0500
Message-ID: [off-list ref]
[2]: http://thread.gmane.org/gmane.linux.kernel.containers/30456/focus=30499
Subject: Re: [CRIU] Introspecting userns relationships to other namespaces?
Date: Thu, 07 Jul 2016 20:20:05 -0700
Message-ID: [off-list ref]
[3]: http://thread.gmane.org/gmane.linux.kernel.containers/30456/focus=20537
Subject: Re: Introspecting userns relationships to other namespaces?
Message-ID: [off-list ref]
Date: Thu, 07 Jul 2016 08:01:52 -0700
[4]: http://thread.gmane.org/gmane.linux.kernel.containers/28925/focus=28928
Subject: [resend][PATCH v9 1/3] procfs: show hierarchy of pid namespace
Date: Tue, 23 Dec 2014 18:20:37 +0800
Message-ID: [off-list ref]
[5]: http://thread.gmane.org/gmane.linux.kernel.containers/28105
Subject: [RFC]Pid conversion between pid namespace
Date: Thu, 3 Jul 2014 12:18:33 +0000
Message-ID: [off-list ref]
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
From: Andrei Vagin <hidden> Date: 2016-07-08 05:41:53
On Thu, Jul 7, 2016 at 8:26 PM, James Bottomley
[off-list ref] wrote:
On Thu, 2016-07-07 at 20:00 -0700, Andrew Vagin wrote:
quoted
On Thu, Jul 07, 2016 at 07:16:18PM -0700, Andrew Vagin wrote:
quoted
On Thu, Jul 07, 2016 at 12:17:35PM -0700, James Bottomley wrote:
quoted
On Thu, 2016-07-07 at 20:21 +0200, Michael Kerrisk (man-pages)
wrote:
quoted
On 7 July 2016 at 17:01, James Bottomley
[off-list ref] wrote:
[Serge already answered the parenting issue]
quoted
quoted
On Thu, 2016-07-07 at 08:36 -0500, Serge E. Hallyn wrote:
quoted
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.
This is a bit pathological, and you have to be root to do it:
so
root can set up a nesting hierarchy, bind it and destroy the
pids
but I know of no current orchestration system which does
this.
Actually, I have to back pedal a bit: the way I currently set
up
architecture emulation containers does precisely this: I set
up the
namespaces unprivileged with child mount namespaces, but then
I ask
root to bind the userns and kill the process that created it
so I
have a permanent handle to enter the namespace by, so I
suspect
that when our current orchestration systems get more
sophisticated,
they might eventually want to do something like this as well.
In theory, we could get nsfs to show this information as an
option
(just add a show_options entry to the superblock ops), but
the
problem is that although each namespace has a parent user_ns,
there's no way to get it without digging in the namespace
specific
structure. Probably we should restructure to move it into
ns_common, then we could display it (and enforce all
namespaces
having owning user_ns) but it would be a
I'm missing something here. Is it not already the case that all
namespaces have an owning user_ns?
Um, yes, I don't believe I said they don't. The problem I
thought you
were having is that there's no way of seeing what it is.
nsfs is the Namespace fileystem where bound namespaces appear to
a cat
of /proc/self/mounts. It can display any information that's in
ns_common (the common core of namespaces) but the owning user_ns
pointer currently isn't in this structure. Every user namespace
has a
pointer to it, but they're all privately embedded in the
individual
namespace specific structures. What I was proposing was that
since
every current namespace has a pointer somewhere to the owning
user
namespace, we could abstract this out into ns_common so it's now
accessible to be displayed by nsfs, probably as a mount option.
James, I am not sure that I understood you correctly. We have one
file system for all namespace files, how we can show per-file
properties
in mount options. I think we can show all required information in
fdinfo. We open a namespaces file (/proc/pid/ns/N) and then read
/proc/pid/fdinfo/X for it.
Here is a proof-of-concept patch.
How it works:
In [1]: import os
In [2]: fd = os.open("/proc/self/ns/pid", os.O_RDONLY)
In [3]: print open("/proc/self/fdinfo/%d" % fd).read()
pos: 0
flags: 0100000
mnt_id: 2
userns: 4026531837
In [4]: print "/proc/self/ns/user -> %s" %
os.readlink("/proc/self/ns/user")
/proc/self/ns/user -> user:[4026531837]
can't you just do
readlink /proc/self/ns/user | sed 's/.*\[\(.*\)\]/\1/'
We can get fdinfo for any ns file. I used /proc/self/ns/pid as an example.
Look at another example:
[root@fc22-vm ~]# cat /proc/self/mountinfo | grep pid_ns_file
115 38 0:3 pid:[4026532306] /tmp/pid_ns_file rw shared:67 - nsfs nsfs rw
In [4]: print open("/proc/self/fdinfo/5").read()
pos: 0
flags: 0100000
mnt_id: 115
userns: 4026532305
In [5]: os.readlink("/proc/self/ns/user")
Out[5]: 'user:[4026531837]'
?
But what Michael was asking about was the parent user_ns of all the
other namespaces ... I don't think there's any way we can get that out
of any information in /proc/self/
James
_______________________________________________
Containers mailing list
Containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
https://lists.linuxfoundation.org/mailman/listinfo/containers
From: Andrei Vagin <hidden> Date: 2016-07-08 05:48:13
On Thu, Jul 7, 2016 at 10:41 PM, Andrei Vagin [off-list ref] wrote:
On Thu, Jul 7, 2016 at 8:26 PM, James Bottomley
[off-list ref] wrote:
quoted
On Thu, 2016-07-07 at 20:00 -0700, Andrew Vagin wrote:
quoted
On Thu, Jul 07, 2016 at 07:16:18PM -0700, Andrew Vagin wrote:
quoted
On Thu, Jul 07, 2016 at 12:17:35PM -0700, James Bottomley wrote:
quoted
On Thu, 2016-07-07 at 20:21 +0200, Michael Kerrisk (man-pages)
wrote:
quoted
On 7 July 2016 at 17:01, James Bottomley
[off-list ref] wrote:
[Serge already answered the parenting issue]
quoted
quoted
On Thu, 2016-07-07 at 08:36 -0500, Serge E. Hallyn wrote:
quoted
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.
This is a bit pathological, and you have to be root to do it:
so
root can set up a nesting hierarchy, bind it and destroy the
pids
but I know of no current orchestration system which does
this.
Actually, I have to back pedal a bit: the way I currently set
up
architecture emulation containers does precisely this: I set
up the
namespaces unprivileged with child mount namespaces, but then
I ask
root to bind the userns and kill the process that created it
so I
have a permanent handle to enter the namespace by, so I
suspect
that when our current orchestration systems get more
sophisticated,
they might eventually want to do something like this as well.
In theory, we could get nsfs to show this information as an
option
(just add a show_options entry to the superblock ops), but
the
problem is that although each namespace has a parent user_ns,
there's no way to get it without digging in the namespace
specific
structure. Probably we should restructure to move it into
ns_common, then we could display it (and enforce all
namespaces
having owning user_ns) but it would be a
I'm missing something here. Is it not already the case that all
namespaces have an owning user_ns?
Um, yes, I don't believe I said they don't. The problem I
thought you
were having is that there's no way of seeing what it is.
nsfs is the Namespace fileystem where bound namespaces appear to
a cat
of /proc/self/mounts. It can display any information that's in
ns_common (the common core of namespaces) but the owning user_ns
pointer currently isn't in this structure. Every user namespace
has a
pointer to it, but they're all privately embedded in the
individual
namespace specific structures. What I was proposing was that
since
every current namespace has a pointer somewhere to the owning
user
namespace, we could abstract this out into ns_common so it's now
accessible to be displayed by nsfs, probably as a mount option.
James, I am not sure that I understood you correctly. We have one
file system for all namespace files, how we can show per-file
properties
in mount options. I think we can show all required information in
fdinfo. We open a namespaces file (/proc/pid/ns/N) and then read
/proc/pid/fdinfo/X for it.
Here is a proof-of-concept patch.
How it works:
In [1]: import os
In [2]: fd = os.open("/proc/self/ns/pid", os.O_RDONLY)
In [3]: print open("/proc/self/fdinfo/%d" % fd).read()
pos: 0
flags: 0100000
mnt_id: 2
userns: 4026531837
In [4]: print "/proc/self/ns/user -> %s" %
os.readlink("/proc/self/ns/user")
/proc/self/ns/user -> user:[4026531837]
can't you just do
readlink /proc/self/ns/user | sed 's/.*\[\(.*\)\]/\1/'
We can get fdinfo for any ns file. I used /proc/self/ns/pid as an example.
Look at another example:
[root@fc22-vm ~]# cat /proc/self/mountinfo | grep pid_ns_file
115 38 0:3 pid:[4026532306] /tmp/pid_ns_file rw shared:67 - nsfs nsfs rw
Sorry, I forgot to say that fd is a file descriptor for /tmp/pid_ns_file
In [2] : fd = os.open("/tmp/pid_ns_file", os.O_RDONLY)
In [3] : fd
Out[4]: 5
In [4]: print open("/proc/self/fdinfo/5").read()
pos: 0
flags: 0100000
mnt_id: 115
userns: 4026532305
In [5]: os.readlink("/proc/self/ns/user")
Out[5]: 'user:[4026531837]'
quoted
?
But what Michael was asking about was the parent user_ns of all the
other namespaces ... I don't think there's any way we can get that out
of any information in /proc/self/
James
_______________________________________________
Containers mailing list
Containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
https://lists.linuxfoundation.org/mailman/listinfo/containers
From: Andrew Vagin <hidden> Date: 2016-07-08 05:52:30
On Thu, Jul 07, 2016 at 12:17:35PM -0700, James Bottomley wrote:
On Thu, 2016-07-07 at 20:21 +0200, Michael Kerrisk (man-pages) wrote:
quoted
On 7 July 2016 at 17:01, James Bottomley
[off-list ref] wrote:
[Serge already answered the parenting issue]
quoted
quoted
On Thu, 2016-07-07 at 08:36 -0500, Serge E. Hallyn wrote:
quoted
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.
This is a bit pathological, and you have to be root to do it: so
root can set up a nesting hierarchy, bind it and destroy the pids
but I know of no current orchestration system which does this.
Actually, I have to back pedal a bit: the way I currently set up
architecture emulation containers does precisely this: I set up the
namespaces unprivileged with child mount namespaces, but then I ask
root to bind the userns and kill the process that created it so I
have a permanent handle to enter the namespace by, so I suspect
that when our current orchestration systems get more sophisticated,
they might eventually want to do something like this as well.
In theory, we could get nsfs to show this information as an option
(just add a show_options entry to the superblock ops), but the
problem is that although each namespace has a parent user_ns,
there's no way to get it without digging in the namespace specific
structure. Probably we should restructure to move it into
ns_common, then we could display it (and enforce all namespaces
having owning user_ns) but it would be a
I'm missing something here. Is it not already the case that all
namespaces have an owning user_ns?
Um, yes, I don't believe I said they don't. The problem I thought you
were having is that there's no way of seeing what it is.
nsfs is the Namespace fileystem where bound namespaces appear to a cat
of /proc/self/mounts. It can display any information that's in
ns_common (the common core of namespaces) but the owning user_ns
pointer currently isn't in this structure. Every user namespace has a
pointer to it, but they're all privately embedded in the individual
namespace specific structures. What I was proposing was that since
every current namespace has a pointer somewhere to the owning user
namespace, we could abstract this out into ns_common so it's now
accessible to be displayed by nsfs, probably as a mount option.
James, I am not sure that I understood you correctly. We have one
file system for all namespace files, how we can show per-file properties
in mount options. I think we can show all required information in
fdinfo. We open a namespaces file (/proc/pid/ns/N) and then read
/proc/pid/fdinfo/X for it.
From: Andrew Vagin <hidden> Date: 2016-07-08 06:10:10
On Thu, Jul 07, 2016 at 08:20:05PM -0700, James Bottomley wrote:
On Thu, 2016-07-07 at 19:16 -0700, Andrew Vagin wrote:
quoted
On Thu, Jul 07, 2016 at 12:17:35PM -0700, James Bottomley wrote:
quoted
On Thu, 2016-07-07 at 20:21 +0200, Michael Kerrisk (man-pages)
wrote:
quoted
On 7 July 2016 at 17:01, James Bottomley
[off-list ref] wrote:
[Serge already answered the parenting issue]
quoted
quoted
On Thu, 2016-07-07 at 08:36 -0500, Serge E. Hallyn wrote:
quoted
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.
This is a bit pathological, and you have to be root to do it:
so
root can set up a nesting hierarchy, bind it and destroy the
pids
but I know of no current orchestration system which does this.
Actually, I have to back pedal a bit: the way I currently set
up
architecture emulation containers does precisely this: I set up
the
namespaces unprivileged with child mount namespaces, but then I
ask
root to bind the userns and kill the process that created it so
I
have a permanent handle to enter the namespace by, so I suspect
that when our current orchestration systems get more
sophisticated,
they might eventually want to do something like this as well.
In theory, we could get nsfs to show this information as an
option
(just add a show_options entry to the superblock ops), but the
problem is that although each namespace has a parent user_ns,
there's no way to get it without digging in the namespace
specific
structure. Probably we should restructure to move it into
ns_common, then we could display it (and enforce all namespaces
having owning user_ns) but it would be a
I'm missing something here. Is it not already the case that all
namespaces have an owning user_ns?
Um, yes, I don't believe I said they don't. The problem I thought
you
were having is that there's no way of seeing what it is.
nsfs is the Namespace fileystem where bound namespaces appear to a
cat
of /proc/self/mounts. It can display any information that's in
ns_common (the common core of namespaces) but the owning user_ns
pointer currently isn't in this structure. Every user namespace
has a
pointer to it, but they're all privately embedded in the individual
namespace specific structures. What I was proposing was that since
every current namespace has a pointer somewhere to the owning user
namespace, we could abstract this out into ns_common so it's now
accessible to be displayed by nsfs, probably as a mount option.
James, I am not sure that I understood you correctly. We have one
file system for all namespace files, how we can show per-file
properties in mount options.
We have two ways of getting information. For a namespace that only
exists as a bind mount we only have what the mount/mountinfo shows, so
you see something like this:
jejb@jarvis:~> mount|grep nsfs
nsfs on /run/build-container/userns type nsfs (rw)
nsfs on /run/build-container/ppc64 type nsfs (rw)
the (rw) are the mount options. We could add the ability to add other
mount options to this via the superblock .show_options callback. We
could make it show the type and parent user namespace.
Yes, we could. But this way works only for bind-mounted ns files, fdinfo
works for any ns files (e.g: /proc/PID/ns/X).
fdinfo show information about one namespace, when /proc/pid/mountinfo
shows infromation about all mounts, so we can parse fdinfo faster and
easier.
quoted
I think we can show all required information in fdinfo. We open a
namespaces file (/proc/pid/ns/N) and then read /proc/pid/fdinfo/X for
it.
Not if we don't have an extant process in the namespace, we can't use
these files because they don't exist, plus fdinfo on the
/proc/<pid>/ns/X doesn't tell you what the parent user_ns of X is
(again, we could add this information somewhere ... not sure where
yet).
we can read fdinfo for any ns file.
For example,
fd = open("/run/build-container/userns", O_PATH);
then read fdinfo for this "fd" (/proc/self/fdinfo/[fd])
Thanks,
Andrew
From: James Bottomley <James.Bottomley@HansenPartnership.com> Date: 2016-07-08 06:14:40
On Thu, 2016-07-07 at 22:41 -0700, Andrei Vagin wrote:
On Thu, Jul 7, 2016 at 8:26 PM, James Bottomley
[off-list ref] wrote:
quoted
On Thu, 2016-07-07 at 20:00 -0700, Andrew Vagin wrote:
quoted
On Thu, Jul 07, 2016 at 07:16:18PM -0700, Andrew Vagin wrote:
quoted
On Thu, Jul 07, 2016 at 12:17:35PM -0700, James Bottomley
wrote:
quoted
On Thu, 2016-07-07 at 20:21 +0200, Michael Kerrisk (man
-pages)
wrote:
quoted
On 7 July 2016 at 17:01, James Bottomley
[off-list ref] wrote:
[Serge already answered the parenting issue]
quoted
quoted
On Thu, 2016-07-07 at 08:36 -0500, Serge E. Hallyn wrote:
quoted
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.
This is a bit pathological, and you have to be root to do
it:
so
root can set up a nesting hierarchy, bind it and destroy
the
pids
but I know of no current orchestration system which does
this.
Actually, I have to back pedal a bit: the way I currently
set
up
architecture emulation containers does precisely this: I
set
up the
namespaces unprivileged with child mount namespaces, but
then
I ask
root to bind the userns and kill the process that created
it
so I
have a permanent handle to enter the namespace by, so I
suspect
that when our current orchestration systems get more
sophisticated,
they might eventually want to do something like this as
well.
In theory, we could get nsfs to show this information as
an
option
(just add a show_options entry to the superblock ops),
but
the
problem is that although each namespace has a parent
user_ns,
there's no way to get it without digging in the namespace
specific
structure. Probably we should restructure to move it
into
ns_common, then we could display it (and enforce all
namespaces
having owning user_ns) but it would be a
I'm missing something here. Is it not already the case that
all
namespaces have an owning user_ns?
Um, yes, I don't believe I said they don't. The problem I
thought you
were having is that there's no way of seeing what it is.
nsfs is the Namespace fileystem where bound namespaces appear
to
a cat
of /proc/self/mounts. It can display any information that's
in
ns_common (the common core of namespaces) but the owning
user_ns
pointer currently isn't in this structure. Every user
namespace
has a
pointer to it, but they're all privately embedded in the
individual
namespace specific structures. What I was proposing was that
since
every current namespace has a pointer somewhere to the owning
user
namespace, we could abstract this out into ns_common so it's
now
accessible to be displayed by nsfs, probably as a mount
option.
James, I am not sure that I understood you correctly. We have
one
file system for all namespace files, how we can show per-file
properties
in mount options. I think we can show all required information
in
fdinfo. We open a namespaces file (/proc/pid/ns/N) and then
read
/proc/pid/fdinfo/X for it.
Here is a proof-of-concept patch.
How it works:
In [1]: import os
In [2]: fd = os.open("/proc/self/ns/pid", os.O_RDONLY)
In [3]: print open("/proc/self/fdinfo/%d" % fd).read()
pos: 0
flags: 0100000
mnt_id: 2
userns: 4026531837
In [4]: print "/proc/self/ns/user -> %s" %
os.readlink("/proc/self/ns/user")
/proc/self/ns/user -> user:[4026531837]
can't you just do
readlink /proc/self/ns/user | sed 's/.*\[\(.*\)\]/\1/'
We can get fdinfo for any ns file. I used /proc/self/ns/pid as an
example.
Look at another example:
[root@fc22-vm ~]# cat /proc/self/mountinfo | grep pid_ns_file
115 38 0:3 pid:[4026532306] /tmp/pid_ns_file rw shared:67 - nsfs nsfs
rw
In [4]: print open("/proc/self/fdinfo/5").read()
pos: 0
flags: 0100000
mnt_id: 115
userns: 4026532305
OK, I'm missing where this is coming from specifically. There would
have to be a show_fdinfo() somewhere that did this and I'm not finding
it in linux-next.
James
From: W. Trevor King <hidden> Date: 2016-07-08 06:16:48
On Thu, Jul 07, 2016 at 10:26:50PM -0700, W. Trevor King wrote:
And if you want to put that whole ancestor tree in fdinfo, you have
to come up with some way to handle the two-parent branching.
Going towards the roots is nice, because you know a given namespace
will only have two parents, but it leaks information about the system
into the container. It's probably better to follow the NStgid,
etc. example and only walk toward the leaves. So a (privileged?)
process in the root namespace could see the whole tree, while a
process in non-root namespaces could only see their namespaces and
descendants. In situations where you were part of a namespace that
belonged to an external user namespace (e.g. you nsenter a child user
namespace but are still in the root PID namespace), you'd want an
“unknown” entry for the parent you couldn't see.
Cheers,
Trevor
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
From: Andrew Vagin <hidden> Date: 2016-07-08 06:55:18
On Thu, Jul 07, 2016 at 10:26:50PM -0700, W. Trevor King wrote:
On Thu, Jul 07, 2016 at 08:26:47PM -0700, James Bottomley wrote:
quoted
On Thu, 2016-07-07 at 20:00 -0700, Andrew Vagin wrote:
quoted
On Thu, Jul 07, 2016 at 07:16:18PM -0700, Andrew Vagin wrote:
quoted
I think we can show all required information in fdinfo. We open
a namespaces file (/proc/pid/ns/N) and then read
/proc/pid/fdinfo/X for it.
Here is a proof-of-concept patch.
…
In [2]: fd = os.open("/proc/self/ns/pid", os.O_RDONLY)
In [3]: print open("/proc/self/fdinfo/%d" % fd).read()
pos: 0
flags: 0100000
mnt_id: 2
userns: 4026531837
In [4]: print "/proc/self/ns/user -> %s" %
os.readlink("/proc/self/ns/user")
/proc/self/ns/user -> user:[4026531837]
can't you just do
readlink /proc/self/ns/user | sed 's/.*\[\(.*\)\]/\1/'
With Andrew's fdinfo approach you know the user namespace owning
/proc/self/ns/pid is 4026531837. That happens to be
/proc/self/ns/user in this case, but doesn't have to be in general.
quoted
But what Michael was asking about was the parent user_ns of all the
other namespaces ... I don't think there's any way we can get that
out of any information in /proc/self/
If fdinfo only shows immediate parents, you'd need to walk the tree to
get back to the root. And at each layer of the PID namespace tree
there will be another user-namespace parent branching off). With a
tree like:
Namespace | Parent | Owning userns
-------------------+--------------+-------------------
Root userns | - | -
Root PID ns | - | Root userns
Child userns | Root usens | Root userns
Child PID ns | Root PID ns | Root userns
Grandchild userns | Child userns | Child userns
Grandchild PID ns | Child PID ns | Grandchild userns
Walking from the granchild PID namespace would give you:
Grandchild PID ns
|-- Child PID ns
| |-- Root PID ns
| `-- Root userns
`-- Granchild userns
`-- Child userns
`-- Root userns
If you only put one level in fdinfo, you're stuck if one of the
namespaces involved has neither bind mounts nor a PID to give you
handle on it [1]. And if you want to put that whole ancestor tree in
fdinfo, you have to come up with some way to handle the two-parent
branching.
I think it's a bad idea to draw a tree in fdinfo. Why do we want to know
this hierarchy? Probably we will want to access these namespaces (setns),
in this case we need to have a way to open them.
Maybe we need to extend functionality of the nsfs filesystem
(somethink like /proc/PID for namespaces)?
I'm also not sure how exposing nsfs information [2] would handle
namespaces that had neither a surviving bind mount nor a direct
process.
If all the information is available (possible after a mechanical patch
[3] makes it more accessible), then it seems easier to put it in a
separate /proc or /sys file. There was a stab at this for PID
namespaces in [4] (the same series that landed NStgid, etc.) with
additional background and alternative approaches in [5]. There were
problems with that patch (and it was trying to do more by also listing
a process's ID in each PID namespace), but the “let's put the whole
tree in a new file” approach seems sound to me.
Cheers,
Trevor
[1]: http://thread.gmane.org/gmane.linux.kernel.containers/30456/focus=20536
Subject: Re: Introspecting userns relationships to other namespaces?
Date: Thu, 7 Jul 2016 13:24:42 -0500
Message-ID: [off-list ref]
[2]: http://thread.gmane.org/gmane.linux.kernel.containers/30456/focus=30499
Subject: Re: [CRIU] Introspecting userns relationships to other namespaces?
Date: Thu, 07 Jul 2016 20:20:05 -0700
Message-ID: [off-list ref]
[3]: http://thread.gmane.org/gmane.linux.kernel.containers/30456/focus=20537
Subject: Re: Introspecting userns relationships to other namespaces?
Message-ID: [off-list ref]
Date: Thu, 07 Jul 2016 08:01:52 -0700
[4]: http://thread.gmane.org/gmane.linux.kernel.containers/28925/focus=28928
Subject: [resend][PATCH v9 1/3] procfs: show hierarchy of pid namespace
Date: Tue, 23 Dec 2014 18:20:37 +0800
Message-ID: [off-list ref]
[5]: http://thread.gmane.org/gmane.linux.kernel.containers/28105
Subject: [RFC]Pid conversion between pid namespace
Date: Thu, 3 Jul 2014 12:18:33 +0000
Message-ID: [off-list ref]
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
From: W. Trevor King <hidden> Date: 2016-07-08 07:19:06
On Thu, Jul 07, 2016 at 11:54:54PM -0700, Andrew Vagin wrote:
On Thu, Jul 07, 2016 at 10:26:50PM -0700, W. Trevor King wrote:
quoted
On Thu, Jul 07, 2016 at 08:26:47PM -0700, James Bottomley wrote:
quoted
On Thu, 2016-07-07 at 20:00 -0700, Andrew Vagin wrote:
quoted
On Thu, Jul 07, 2016 at 07:16:18PM -0700, Andrew Vagin wrote:
quoted
I think we can show all required information in fdinfo. We open
a namespaces file (/proc/pid/ns/N) and then read
/proc/pid/fdinfo/X for it.
Here is a proof-of-concept patch.
…
In [2]: fd = os.open("/proc/self/ns/pid", os.O_RDONLY)
In [3]: print open("/proc/self/fdinfo/%d" % fd).read()
pos: 0
flags: 0100000
mnt_id: 2
userns: 4026531837
In [4]: print "/proc/self/ns/user -> %s" %
os.readlink("/proc/self/ns/user")
/proc/self/ns/user -> user:[4026531837]
can't you just do
readlink /proc/self/ns/user | sed 's/.*\[\(.*\)\]/\1/'
…
If you only put one level in fdinfo, you're stuck if one of the
namespaces involved has neither bind mounts nor a PID to give you
handle on it [1]. And if you want to put that whole ancestor tree in
fdinfo, you have to come up with some way to handle the two-parent
branching.
I think it's a bad idea to draw a tree in fdinfo. Why do we want to know
this hierarchy? Probably we will want to access these namespaces (setns),
in this case we need to have a way to open them.
Maybe we need to extend functionality of the nsfs filesystem
(somethink like /proc/PID for namespaces)?
A similar idea came up during the PID-translation brainstorming [1],
but I'm not sure if anything ever came of that. Once you're dealing
with a separate pseudo-filesystem, it seems easier to decouple it from
proc and just make a mountable namespace-hierarchy filesystem (like we
have mountable cgroup hierarchy filesystems). That also gets you an
opt-in playground while the details of the nsfs filesystem view are
worked out. Are you imagining something like:
$ tree .
.
├── mnt{inum}
│ └── user -> ../user{inum}
├── pid{inum}
│ ├── pid{inum}
│ │ └── user -> ../../user{inum}/user{inum}
│ └── user -> ../user{inum}
└── user{inum}
└── user{inum}
Cheers,
Trevor
[1]: http://thread.gmane.org/gmane.linux.kernel.containers/28105/focus=28164
Subject: RE: [RFC]Pid conversion between pid namespace
Date: Fri, 25 Jul 2014 10:01:45 +0000
Message-ID: [off-list ref]
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
From: Michael Kerrisk (man-pages) <hidden> Date: 2016-07-08 11:11:57
On 07/07/2016 09:17 PM, James Bottomley wrote:
On Thu, 2016-07-07 at 20:21 +0200, Michael Kerrisk (man-pages) wrote:
quoted
On 7 July 2016 at 17:01, James Bottomley
[off-list ref] wrote:
[Serge already answered the parenting issue]
quoted
quoted
On Thu, 2016-07-07 at 08:36 -0500, Serge E. Hallyn wrote:
quoted
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.
This is a bit pathological, and you have to be root to do it: so
root can set up a nesting hierarchy, bind it and destroy the pids
but I know of no current orchestration system which does this.
Actually, I have to back pedal a bit: the way I currently set up
architecture emulation containers does precisely this: I set up the
namespaces unprivileged with child mount namespaces, but then I ask
root to bind the userns and kill the process that created it so I
have a permanent handle to enter the namespace by, so I suspect
that when our current orchestration systems get more sophisticated,
they might eventually want to do something like this as well.
In theory, we could get nsfs to show this information as an option
(just add a show_options entry to the superblock ops), but the
problem is that although each namespace has a parent user_ns,
there's no way to get it without digging in the namespace specific
structure. Probably we should restructure to move it into
ns_common, then we could display it (and enforce all namespaces
having owning user_ns) but it would be a
I'm missing something here. Is it not already the case that all
namespaces have an owning user_ns?
Um, yes, I don't believe I said they don't. The problem I thought you
were having is that there's no way of seeing what it is.
Your words "and enforce all namespaces having owning user_ns" were
what left me puzzled--it sounded to me that the implication was
that this is not "enforced" right now.
Cheers,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
From: Michael Kerrisk (man-pages) <hidden> Date: 2016-07-08 11:18:18
On 07/08/2016 05:26 AM, James Bottomley wrote:
On Thu, 2016-07-07 at 20:00 -0700, Andrew Vagin wrote:
quoted
On Thu, Jul 07, 2016 at 07:16:18PM -0700, Andrew Vagin wrote:
quoted
On Thu, Jul 07, 2016 at 12:17:35PM -0700, James Bottomley wrote:
quoted
On Thu, 2016-07-07 at 20:21 +0200, Michael Kerrisk (man-pages)
wrote:
quoted
On 7 July 2016 at 17:01, James Bottomley
[off-list ref] wrote:
[Serge already answered the parenting issue]
quoted
quoted
On Thu, 2016-07-07 at 08:36 -0500, Serge E. Hallyn wrote:
quoted
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.
This is a bit pathological, and you have to be root to do it:
so
root can set up a nesting hierarchy, bind it and destroy the
pids
but I know of no current orchestration system which does
this.
Actually, I have to back pedal a bit: the way I currently set
up
architecture emulation containers does precisely this: I set
up the
namespaces unprivileged with child mount namespaces, but then
I ask
root to bind the userns and kill the process that created it
so I
have a permanent handle to enter the namespace by, so I
suspect
that when our current orchestration systems get more
sophisticated,
they might eventually want to do something like this as well.
In theory, we could get nsfs to show this information as an
option
(just add a show_options entry to the superblock ops), but
the
problem is that although each namespace has a parent user_ns,
there's no way to get it without digging in the namespace
specific
structure. Probably we should restructure to move it into
ns_common, then we could display it (and enforce all
namespaces
having owning user_ns) but it would be a
I'm missing something here. Is it not already the case that all
namespaces have an owning user_ns?
Um, yes, I don't believe I said they don't. The problem I
thought you
were having is that there's no way of seeing what it is.
nsfs is the Namespace fileystem where bound namespaces appear to
a cat
of /proc/self/mounts. It can display any information that's in
ns_common (the common core of namespaces) but the owning user_ns
pointer currently isn't in this structure. Every user namespace
has a
pointer to it, but they're all privately embedded in the
individual
namespace specific structures. What I was proposing was that
since
every current namespace has a pointer somewhere to the owning
user
namespace, we could abstract this out into ns_common so it's now
accessible to be displayed by nsfs, probably as a mount option.
James, I am not sure that I understood you correctly. We have one
file system for all namespace files, how we can show per-file
properties
in mount options. I think we can show all required information in
fdinfo. We open a namespaces file (/proc/pid/ns/N) and then read
/proc/pid/fdinfo/X for it.
Here is a proof-of-concept patch.
How it works:
In [1]: import os
In [2]: fd = os.open("/proc/self/ns/pid", os.O_RDONLY)
In [3]: print open("/proc/self/fdinfo/%d" % fd).read()
pos: 0
flags: 0100000
mnt_id: 2
userns: 4026531837
In [4]: print "/proc/self/ns/user -> %s" %
os.readlink("/proc/self/ns/user")
/proc/self/ns/user -> user:[4026531837]
can't you just do
readlink /proc/self/ns/user | sed 's/.*\[\(.*\)\]/\1/'
?
But what Michael was asking about was the parent user_ns of all the
other namespaces ...
Just to reiterate, what I'm interested in is the introspection use
case (but there's clearly several other interesting use cases here).
The idea is to be able to answer these questions
1. For each userns, what is the parent of that userns?
2. For each non-user namespace, what is the owning userns?
This enables us to understand the userns hierarchy, which
matters in terms of answering the question: what capabilities
does process X have in namespace Y?
Cheers,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
From: W. Trevor King <hidden> Date: 2016-07-09 03:15:41
On Thu, Jul 07, 2016 at 08:01:52AM -0700, James Bottomley wrote:
In theory, we could get nsfs to show this information as an option
(just add a show_options entry to the superblock ops), but the
problem is that although each namespace has a parent user_ns,
there's no way to get it without digging in the namespace specific
structure. Probably we should restructure to move it into
ns_common, then we could display it (and enforce all namespaces
having owning user_ns) but it would be a reasonably large (but
mechanical) change.
It sounds like everyone is either positive or or neutral on this
groundwork, even if we haven't decided if/how to expose the
information to userspace. I'm happy to work up a patch while the rest
of the discussion continues. I'm also happy to let someone else work
up the patch, if anyone else is chomping at the bit ;).
Cheers,
Trevor
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy