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

[ebiederm@xmission.com (Eric W. Biederman)]

Andrew Vagin <avagin@virtuozzo.com> writes:

> On Fri, Jul 08, 2016 at 10:13:08PM -0500, Eric W. Biederman wrote:
>> "W. Trevor King" <wking@tremily.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