On 07/07/2016 09:17 PM, James Bottomley wrote:
On Thu, 2016-07-07 at 20:21 +0200, Michael Kerrisk (man-pages) wrote:
On 7 July 2016 at 17:01, James Bottomley
<James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> wrote:
[Serge already answered the parenting issue]
On Thu, 2016-07-07 at 08:36 -0500, Serge E. Hallyn wrote:
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/
--
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
