Re: [CRIU] Introspecting userns relationships to other namespaces?

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

James