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@mail.hallyn.com> [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@HansenPartnership.com> [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@HansenPartnership.com> 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@cn.fujitsu.com> [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