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:
> > On Thu, Jul 07, 2016 at 07:16:18PM -0700, Andrew Vagin wrote:
> > > 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: <20160707182442.GA6402@xxxxxxxxxxxxxxx>
[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: <1467948005.2322.84.camel@xxxxxxxxxxxxxxxxxxxxx>
[3]: http://thread.gmane.org/gmane.linux.kernel.containers/30456/focus=20537
Subject: Re: Introspecting userns relationships to other namespaces?
Message-ID: <1467903712.2347.16.camel@xxxxxxxxxxxxxxxxxxxxx>
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: <1419330039-29207-2-git-send-email-chenhanxiao@xxxxxxxxxxxxxx>
[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: <5871495633F38949900D2BF2DC04883E55C374@G08CNEXMBPEKD02.g08.fujitsu.local>
--
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
Attachment:
signature.asc
Description: OpenPGP digital signature
