linux-kernel - Re: [CRIU] 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]

Date:	Sun, 10 Jul 2016 15:29:47 -0500
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Andrew Vagin <avagin@...tuozzo.com>
Cc:	"W. Trevor King" <wking@...mily.us>, <criu@...nvz.org>,
	Linux API <linux-api@...r.kernel.org>,
	Containers <containers@...ts.linux-foundation.org>,
	lkml <linux-kernel@...r.kernel.org>,
	James Bottomley <James.Bottomley@...senPartnership.com>,
	"Michael Kerrisk \(man-pages\)" <mtk.manpages@...il.com>,
	"Serge E. Hallyn" <serge@...lyn.com>
Subject: Re: [CRIU] Introspecting userns relationships to other namespaces?

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/63b32df68ae8d3a3842bae42bbcae3468db76d85
>
> I can't say that it makes something uglier.

I have only skimmed things but overall it looks better than I had
feared.

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

Eric