lkml.org 
[lkml]   [2016]   [Jul]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
Date
From
SubjectRe: [CRIU] Introspecting userns relationships to other namespaces?
On Mon, Jul 11, 2016 at 06:06:48AM +0900, James Bottomley wrote:
> On Sun, 2016-07-10 at 15:29 -0500, Eric W. Biederman wrote:
> > 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/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.

We can do something like this:

@@ -27,11 +27,13 @@ struct user_namespace {
...
- struct ns_common ns;
+ union {
+ struct user_namespace *parent;
+ struct ns_common ns;
+ };
unsigned long flags;
...
@@ -97,6 +97,7 @@ int create_user_ns(struct cred *new)
...
atomic_set(&ns->count, 1);
/* Leave the new->user_ns reference with the new user namespace. */
+ BUILD_BUG_ON(&ns->ns.user_ns != &ns->parent);
ns->parent = parent_ns;

>
> 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.

I think we can rename ns.user_ns to ns.owner or ns.owner_ns.

Thanks,
Andrew

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

\
 
 \ /
  Last update: 2016-07-12 00:01    [W:0.076 / U:2.800 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site