linux-kernel - Re: Introspecting userns relationships to other namespaces?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160708065453.GB14391@outlook.office365.com>
Date:	Thu, 7 Jul 2016 23:54:54 -0700
From:	Andrew Vagin <avagin@...tuozzo.com>
To:	"W. Trevor King" <wking@...mily.us>
CC:	James Bottomley <James.Bottomley@...senPartnership.com>,
	<criu@...nvz.org>, Linux API <linux-api@...r.kernel.org>,
	Containers <containers@...ts.linux-foundation.org>,
	lkml <linux-kernel@...r.kernel.org>, <mtk.manpages@...il.com>
Subject: Re: Introspecting userns relationships to other namespaces?

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:
> > 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 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: <20160707182442.GA6402@...l.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@...senPartnership.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@...senPartnership.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@...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@...CNEXMBPEKD02.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