Re: [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:

quoted

Andrew Vagin [off-list ref] writes:

quoted

On Fri, Jul 08, 2016 at 10:13:08PM -0500, Eric W. Biederman wrote:

quoted

"W. Trevor King" [off-list ref] writes:

quoted

On Thu, Jul 07, 2016 at 08:01:52AM -0700, James Bottomley
wrote:

quoted

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.

quoted

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

quoted

Eric

_______________________________________________
Containers mailing list
Containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
https://lists.linuxfoundation.org/mailman/listinfo/containers