From: James Bottomley <James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk@public.gmane.org>
To: "Eric W. Biederman"
<ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>,
Andrew Vagin <avagin-5HdwGun5lf+gSpxsJD1C4w@public.gmane.org>
Cc: criu-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org,
Linux API <linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Containers
<containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>,
lkml <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"Michael Kerrisk (man-pages)"
<mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Subject: Re: [CRIU] Introspecting userns relationships to other namespaces?
Date: Mon, 11 Jul 2016 06:06:48 +0900 [thread overview]
Message-ID: <1468184808.19833.30.camel@HansenPartnership.com> (raw)
In-Reply-To: <87furhjkxw.fsf-JOvCrm2gF+uungPnsOpG7nhyD016LWXt@public.gmane.org>
On Sun, 2016-07-10 at 15:29 -0500, Eric W. Biederman wrote:
> Andrew Vagin <avagin-5HdwGun5lf+gSpxsJD1C4w@public.gmane.org> writes:
>
> > On Fri, Jul 08, 2016 at 10:13:08PM -0500, Eric W. Biederman wrote:
> > > "W. Trevor King" <wking-vJI2gpByivqcqzYg7KEe8g@public.gmane.org> 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
>
WARNING: multiple messages have this Message-ID (diff)
From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>,
Andrew Vagin <avagin@virtuozzo.com>
Cc: Linux API <linux-api@vger.kernel.org>,
Containers <containers@lists.linux-foundation.org>,
lkml <linux-kernel@vger.kernel.org>,
criu@openvz.org,
"Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com>
Subject: Re: [CRIU] Introspecting userns relationships to other namespaces?
Date: Mon, 11 Jul 2016 06:06:48 +0900 [thread overview]
Message-ID: <1468184808.19833.30.camel@HansenPartnership.com> (raw)
In-Reply-To: <87furhjkxw.fsf@x220.int.ebiederm.org>
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.
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@lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/containers
>
next prev parent reply other threads:[~2016-07-10 21:06 UTC|newest]
Thread overview: 111+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <c2a26220-69f2-f2f5-491a-e43abd9a6f92@gmail.com>
[not found] ` <87r3b7pxja.fsf@x220.int.ebiederm.org>
[not found] ` <87r3b7pxja.fsf-JOvCrm2gF+uungPnsOpG7nhyD016LWXt@public.gmane.org>
2016-07-06 8:41 ` Introspecting userns relationships to other namespaces? Michael Kerrisk (man-pages)
2016-07-06 8:41 ` Michael Kerrisk (man-pages)
[not found] ` <CAKgNAkgQbxLH-B3N3Xti3LLis+1Y-SJD2h1DEaXao7zTDA7pug-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-07-06 14:13 ` Serge E. Hallyn
2016-07-06 14:13 ` Serge E. Hallyn
2016-07-06 14:13 ` Serge E. Hallyn
[not found] ` <20160706141348.GB20728-7LNsyQBKDXoIagZqoN9o3w@public.gmane.org>
2016-07-06 15:46 ` Eric W. Biederman
2016-07-06 15:46 ` Eric W. Biederman
[not found] ` <871t36kbvq.fsf-JOvCrm2gF+uungPnsOpG7nhyD016LWXt@public.gmane.org>
2016-07-08 1:57 ` [CRIU] " Andrew Vagin
2016-07-08 1:57 ` Andrew Vagin
[not found] ` <20160708015758.GA10512-1ViLX0X+lBJGNQ1M2rI3KwRV3xvJKrda@public.gmane.org>
2016-07-08 7:44 ` Eric W. Biederman
2016-07-08 7:44 ` Eric W. Biederman
[not found] ` <87vb0gy3nr.fsf-JOvCrm2gF+uungPnsOpG7nhyD016LWXt@public.gmane.org>
2016-07-08 14:35 ` James Bottomley
2016-07-08 14:35 ` James Bottomley
[not found] ` <1467988533.2322.118.camel-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk@public.gmane.org>
2016-07-08 20:38 ` Andrew Vagin
2016-07-08 20:38 ` Andrew Vagin
[not found] ` <20160708203818.GA2602-1ViLX0X+lBJGNQ1M2rI3KwRV3xvJKrda@public.gmane.org>
2016-07-08 20:50 ` W. Trevor King
2016-07-08 20:50 ` W. Trevor King
2016-07-08 20:50 ` W. Trevor King
2016-07-08 22:19 ` James Bottomley
2016-07-08 22:19 ` James Bottomley
2016-07-08 22:19 ` James Bottomley
2016-07-08 22:19 ` James Bottomley
2016-07-08 22:19 ` James Bottomley
[not found] ` <5e4cc802-f0e0-4f4c-a2f7-585aaaa8feec-2ueSQiBKiTY7tOexoI0I+QC/G2K4zDHf@public.gmane.org>
2016-07-08 23:52 ` Eric W. Biederman
2016-07-08 23:52 ` Eric W. Biederman
2016-07-08 23:52 ` Eric W. Biederman
[not found] ` <87wpkvpu1i.fsf-JOvCrm2gF+uungPnsOpG7nhyD016LWXt@public.gmane.org>
2016-07-09 0:15 ` James Bottomley
2016-07-09 0:15 ` James Bottomley
2016-07-09 0:15 ` James Bottomley
[not found] ` <1468023332.2390.10.camel-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk@public.gmane.org>
2016-07-09 3:05 ` Eric W. Biederman
2016-07-09 3:05 ` Eric W. Biederman
[not found] ` <87bn27o6j5.fsf-JOvCrm2gF+uungPnsOpG7nhyD016LWXt@public.gmane.org>
2016-07-09 7:26 ` Andrew Vagin
2016-07-09 7:26 ` Andrew Vagin
[not found] ` <20160709072627.GA7480-1ViLX0X+lBJGNQ1M2rI3KwRV3xvJKrda@public.gmane.org>
2016-07-09 10:31 ` James Bottomley
2016-07-09 10:31 ` James Bottomley
2016-07-09 10:31 ` James Bottomley
2016-07-09 10:32 ` James Bottomley
2016-07-09 10:32 ` James Bottomley
2016-07-09 18:15 ` Eric W. Biederman
2016-07-09 18:15 ` Eric W. Biederman
2016-07-09 18:15 ` Eric W. Biederman
[not found] ` <87eg72llu0.fsf-JOvCrm2gF+uungPnsOpG7nhyD016LWXt@public.gmane.org>
2016-07-09 18:29 ` Eric W. Biederman
2016-07-09 18:29 ` Eric W. Biederman
[not found] ` <871t32ll6n.fsf-JOvCrm2gF+uungPnsOpG7nhyD016LWXt@public.gmane.org>
2016-07-13 0:08 ` Andrew Vagin
2016-07-13 0:08 ` Andrew Vagin
[not found] ` <20160713000842.GC5818-1ViLX0X+lBJGNQ1M2rI3KwRV3xvJKrda@public.gmane.org>
2016-07-13 3:59 ` W. Trevor King
2016-07-13 3:59 ` W. Trevor King
2016-07-08 22:19 ` James Bottomley
2016-07-08 7:44 ` Eric W. Biederman
2016-07-07 8:15 ` Michael Kerrisk (man-pages)
2016-07-07 8:15 ` Michael Kerrisk (man-pages)
[not found] ` <CAKgNAkhtQNg0mVv6ei_JigNz3njo_G3opE+rzd4OtKpa2hQe9g-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-07-07 13:36 ` Serge E. Hallyn
2016-07-07 13:36 ` Serge E. Hallyn
[not found] ` <20160707133631.GA2994-7LNsyQBKDXoIagZqoN9o3w@public.gmane.org>
2016-07-07 15:01 ` James Bottomley
2016-07-07 15:01 ` James Bottomley
2016-07-07 15:01 ` James Bottomley
[not found] ` <1467903712.2347.16.camel-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk@public.gmane.org>
2016-07-07 18:21 ` Michael Kerrisk (man-pages)
2016-07-07 18:21 ` Michael Kerrisk (man-pages)
[not found] ` <CAKgNAkg+OiBngdFsdVR0gsSnVhMppuH2DxMBLCNAx8in5C0-zQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-07-07 18:24 ` Serge E. Hallyn
2016-07-07 18:24 ` Serge E. Hallyn
2016-07-07 18:24 ` Serge E. Hallyn
2016-07-07 19:17 ` James Bottomley
2016-07-07 19:17 ` James Bottomley
[not found] ` <1467919055.2322.36.camel-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk@public.gmane.org>
2016-07-08 2:16 ` [CRIU] " Andrew Vagin
2016-07-08 2:16 ` Andrew Vagin
[not found] ` <20160708021617.GB10512-1ViLX0X+lBJGNQ1M2rI3KwRV3xvJKrda@public.gmane.org>
2016-07-08 3:00 ` Andrew Vagin
2016-07-08 3:00 ` Andrew Vagin
[not found] ` <20160708030055.GC10512-1ViLX0X+lBJGNQ1M2rI3KwRV3xvJKrda@public.gmane.org>
2016-07-08 3:26 ` James Bottomley
2016-07-08 3:26 ` James Bottomley
2016-07-08 3:26 ` James Bottomley
[not found] ` <1467948407.2322.88.camel-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk@public.gmane.org>
2016-07-08 5:26 ` W. Trevor King
2016-07-08 5:26 ` W. Trevor King
2016-07-08 5:26 ` W. Trevor King
[not found] ` <20160708052650.GM4916-q4NCUed9G3sTnwFZoN752g@public.gmane.org>
2016-07-08 6:16 ` W. Trevor King
2016-07-08 6:16 ` W. Trevor King
2016-07-08 6:16 ` W. Trevor King
2016-07-08 6:54 ` Andrew Vagin
2016-07-08 6:54 ` Andrew Vagin
[not found] ` <20160708065453.GB14391-1ViLX0X+lBJGNQ1M2rI3KwRV3xvJKrda@public.gmane.org>
2016-07-08 7:18 ` W. Trevor King
2016-07-08 7:18 ` W. Trevor King
2016-07-08 7:18 ` W. Trevor King
2016-07-08 5:41 ` [CRIU] " Andrei Vagin
2016-07-08 5:41 ` Andrei Vagin
2016-07-08 5:41 ` Andrei Vagin
[not found] ` <CANaxB-wBkHrsQXcruEDXWwU-X8y4szW3dgVd+9JvgCGrrNeW4g-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-07-08 5:47 ` Andrei Vagin
2016-07-08 5:47 ` Andrei Vagin
2016-07-08 6:07 ` James Bottomley
2016-07-08 6:07 ` James Bottomley
2016-07-08 11:17 ` Michael Kerrisk (man-pages)
2016-07-08 11:17 ` Michael Kerrisk (man-pages)
2016-07-08 3:20 ` James Bottomley
2016-07-08 3:20 ` James Bottomley
[not found] ` <1467948005.2322.84.camel-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk@public.gmane.org>
2016-07-08 6:09 ` Andrew Vagin
2016-07-08 6:09 ` Andrew Vagin
2016-07-08 11:11 ` Michael Kerrisk (man-pages)
2016-07-08 11:11 ` Michael Kerrisk (man-pages)
2016-07-07 19:17 ` James Bottomley
2016-07-09 3:15 ` W. Trevor King
2016-07-09 3:15 ` W. Trevor King
[not found] ` <20160709031528.GA25507-q4NCUed9G3sTnwFZoN752g@public.gmane.org>
2016-07-09 3:13 ` Eric W. Biederman
2016-07-09 3:13 ` Eric W. Biederman
[not found] ` <87ziprmrln.fsf-JOvCrm2gF+uungPnsOpG7nhyD016LWXt@public.gmane.org>
2016-07-10 5:36 ` [CRIU] " Andrew Vagin
2016-07-10 5:36 ` Andrew Vagin
[not found] ` <20160710053609.GB4868-1ViLX0X+lBJGNQ1M2rI3KwRV3xvJKrda@public.gmane.org>
2016-07-10 20:29 ` Eric W. Biederman
2016-07-10 20:29 ` Eric W. Biederman
2016-07-10 20:29 ` Eric W. Biederman
[not found] ` <87furhjkxw.fsf-JOvCrm2gF+uungPnsOpG7nhyD016LWXt@public.gmane.org>
2016-07-10 21:06 ` James Bottomley [this message]
2016-07-10 21:06 ` James Bottomley
[not found] ` <1468184808.19833.30.camel-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk@public.gmane.org>
2016-07-11 20:55 ` Andrew Vagin
2016-07-11 20:55 ` Andrew Vagin
2016-07-09 3:15 ` W. Trevor King
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1468184808.19833.30.camel@HansenPartnership.com \
--to=james.bottomley-d9phhud1jfjcxq6kfmz53/egyhegw8jk@public.gmane.org \
--cc=avagin-5HdwGun5lf+gSpxsJD1C4w@public.gmane.org \
--cc=containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
--cc=criu-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org \
--cc=ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org \
--cc=linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.