# Re: \[CRIU\] Introspecting userns relationships to other namespaces? - List: linux-api - 3 messages, 3 authors - Page: https://ratatoskr.run/linux-api/2016/07/4791706/t ## Re: \[CRIU\] Introspecting userns relationships to other namespaces? - From: Eric W. Biederman \ - Date: 2016-07-10 20:42:20 - Message: https://ratatoskr.run/linux-api/2016/07/4791706.md ```text Andrew Vagin [ref] writes: > On Fri, Jul 08, 2016 at 10:13:08PM -0500, Eric W. Biederman wrote: >> "W. Trevor King" [ref] 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 ``` ## Re: \[CRIU\] Introspecting userns relationships to other namespaces? - From: James Bottomley \ - Date: 2016-07-10 21:06:58 - Message: https://ratatoskr.run/linux-api/2016/07/4791707.md ```text On Sun, 2016-07-10 at 15:29 -0500, Eric W. Biederman wrote: > Andrew Vagin [ref] writes: > > > On Fri, Jul 08, 2016 at 10:13:08PM -0500, Eric W. Biederman wrote: > > > "W. Trevor King" [ref] 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. 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. James > Eric > > _______________________________________________ > Containers mailing list > Containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org > https://lists.linuxfoundation.org/mailman/listinfo/containers > ``` ## Re: \[CRIU\] Introspecting userns relationships to other namespaces? - From: Andrew Vagin \ - Date: 2016-07-11 21:09:37 - Message: https://ratatoskr.run/linux-api/2016/07/4792455.md ```text 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 [ref] writes: > > > > > On Fri, Jul 08, 2016 at 10:13:08PM -0500, Eric W. Biederman wrote: > > > > "W. Trevor King" [ref] 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-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org > > https://lists.linuxfoundation.org/mailman/listinfo/containers > > > ```