Re: [CRIU] Introspecting userns relationships to other namespaces?
From: Eric W. Biederman
Date: Sun Jul 10 2016 - 16:42:35 EST
Andrew Vagin <avagin@xxxxxxxxxxxxx> writes:
> On Fri, Jul 08, 2016 at 10:13:08PM -0500, Eric W. Biederman wrote:
>> "W. Trevor King" <wking@xxxxxxxxxx> 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