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

Open Source and information security mailing list archives

Date:	Mon, 11 Jul 2016 06:06:48 +0900
From:	James Bottomley <James.Bottomley@...senPartnership.com>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Andrew Vagin <avagin@...tuozzo.com>
Cc:	Linux API <linux-api@...r.kernel.org>,
	Containers <containers@...ts.linux-foundation.org>,
	lkml <linux-kernel@...r.kernel.org>, criu@...nvz.org,
	"Michael Kerrisk (man-pages)" <mtk.manpages@...il.com>
Subject: Re: [CRIU] Introspecting userns relationships to other namespaces?

On Sun, 2016-07-10 at 15:29 -0500, Eric W. Biederman wrote:
> Andrew Vagin <avagin@...tuozzo.com> writes:
> 
> > On Fri, Jul 08, 2016 at 10:13:08PM -0500, Eric W. Biederman wrote:
> > > "W. Trevor King" <wking@...mily.us> writes:
> > > 
> > > > On Thu, Jul 07, 2016 at 08:01:52AM -0700, James Bottomley
> > > > wrote:
> > > > > 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 reasonably large
> > > > > (but
> > > > > mechanical) change.
> > > > 
> > > > It sounds like everyone is either positive or or neutral on
> > > > this
> > > > groundwork, even if we haven't decided if/how to expose the
> > > > information to userspace.  I'm happy to work up a patch while
> > > > the rest
> > > > of the discussion continues.  I'm also happy to let someone
> > > > else work
> > > > up the patch, if anyone else is chomping at the bit ;).
> > > 
> > > I am dubious on moving all of the user namespace members into
> > > ns_common.
> > > 
> > > I would happy to be proved wrong but I suspect in the cases where
> > > we
> > > actually use that user namespace the code will become uglier. 
> > >  Making
> > > the ordinary uses uglier to make a rare corner case nicer is the
> > > wrong
> > > trade off.
> > > 
> > > But feel free to try it is certainly worth doing if it doesn't
> > > make the
> > > code that uses the user namespaces uglier.
> > 
> > If it's interesting for someone, I have this patch in my tree
> > https://github.com/avagin/linux-task-diag/commit/63b32df68ae8d3a384
> > 2bae42bbcae3468db76d85
> > 
> > I can't say that it makes something uglier.
> 
> I have only skimmed things but overall it looks better than I had
> feared.

It looks about as messy as I feared, but since someone else has done
all the hard work, I'm happy.

> At the same time I really really don't like losing the parent pointer 
> in the user namespace case.  That is seriously obfuscating.

Because it has a slightly different meaning from all other namespaces? 
 If I assume that's what you mean, I think looking at it in a different
way can solve the problem:  The pointer in ns_common is always to the
owning user_ns, so we can label it as such.  Even for a child user_ns,
the owning user_ns is simply the parent.  I think it makes logical
sense to think of all user_ns to namespace relationships as
owning/owned rather than most as owning/owned and some as parent/child.

James

> Eric
> 
> _______________________________________________
> Containers mailing list
> Containers@...ts.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/containers
> 

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