From: "W. Trevor King" <wking@tremily.us>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: James Bottomley <James.Bottomley@HansenPartnership.com>,
Andrey Vagin <avagin@openvz.org>,
Serge Hallyn <serge.hallyn@canonical.com>,
linux-api@vger.kernel.org, containers@lists.linux-foundation.org,
linux-kernel@vger.kernel.org,
Alexander Viro <viro@zeniv.linux.org.uk>,
criu@openvz.org, linux-fsdevel@vger.kernel.org,
"Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com>
Subject: Re: [PATCH 0/5 RFC] Add an interface to discover relationships between namespaces
Date: Sat, 23 Jul 2016 15:34:48 -0700 [thread overview]
Message-ID: <20160723223448.GP24913@odin.tremily.us> (raw)
In-Reply-To: <87mvl8nhlv.fsf@x220.int.ebiederm.org>
[-- Attachment #1: Type: text/plain, Size: 3203 bytes --]
On Sat, Jul 23, 2016 at 04:56:44PM -0500, Eric W. Biederman wrote:
> "W. Trevor King" <wking@tremily.us> writes:
> > On Sat, Jul 23, 2016 at 02:38:56PM -0700, James Bottomley wrote:
> >> On Sat, 2016-07-23 at 14:14 -0700, W. Trevor King wrote:
> >> > namespaces(7) and clone(2) both have:
> >> >
> >> > When a network namespace is freed (i.e., when the last
> >> > process in the namespace terminates), its physical network
> >> > devices are moved back to the initial network namespace (not
> >> > to the parent of the process).
> >> >
> >> > So the initial network namespace (the head of
> >> > net_namespace_list?) is special [1]. To understand how
> >> > physical network devices will be handled, it seems like we want
> >> > to treat network devices as a depth-1 tree, with all
> >> > non-initial net namespaces as children of the initial net
> >> > namespace. Can we extend this series' NS_GET_PARENT to return:
> >> >
> >> > * EPERM for an unprivileged caller (like this series currently
> >> > does for PID namespaces),
> >> > * ENOENT when called on net_namespace_list, and
> >> > * net_namespace_list when called on any other net namespace.
> >>
> >> What's the practical application of this? independent net
> >> namespaces are managed by the ip netns command. It pins them by
> >> a bind mount in a flat fashion; if we make them hierarchical the
> >> tool would probably need updating to reflect this, so we're going
> >> to need a reason to give the network people. Just having the
> >> interfaces not go back to root when you do an ip netns delete
> >> doesn't seem very compelling.
> >
> > I'm not suggesting we add support for deeper nesting, I'm suggesting
> > we use NS_GET_PARENT to allow sufficiently privileged users to
> > determine if a given net namespace is the initial net namespace. You
> > could do this already with something like:
> >
> > 1. Create a new net namespace.
> > 2. Add a physical network device to that namespace.
> > 3. Delete that namespace.
> > 4. See if the physical network device shows up in your
> > initial-net-namespace candidate.
> > 5. Delete the physical network device (hopefully it ended up
> > somewhere you can find it ;).
> >
> > But using an NS_GET_PARENT call seems much safer and easier.
>
> Have you had the problem in practice where you can't tell which
> network namespace is the initial network namespace. This all seems
> like a theoretical problem rather than a real one.
I haven't had any practical problems here, I'm just trying to wrap my
head around namespace-relationship discovery. The special physical
network device handling seems a lot like init re-parenting (with no
PR_SET_CHILD_SUBREAPER analog in a 1-deep namespace tree), so calling
the initial network namespace a parent (and all the other namespaces
its direct children) seems natural enough. If that doesn't sound
convincing, I'm happy to punt this idea until someone runs into a
practical problem ;).
Cheers,
Trevor
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
next prev parent reply other threads:[~2016-07-23 22:36 UTC|newest]
Thread overview: 62+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-14 18:20 [PATCH 0/5 RFC] Add an interface to discover relationships between namespaces Andrey Vagin
2016-07-14 18:20 ` [PATCH 1/5] namespaces: move user_ns into ns_common Andrey Vagin
2016-07-15 12:21 ` kbuild test robot
2016-07-14 18:20 ` [PATCH 2/5] kernel: add a helper to get an owning user namespace for a namespace Andrey Vagin
2016-07-14 19:07 ` W. Trevor King
2016-07-14 18:20 ` [PATCH 3/5] nsfs: add ioctl to get an owning user namespace for ns file descriptor Andrey Vagin
2016-07-14 18:48 ` W. Trevor King
2016-07-14 18:20 ` [PATCH 4/5] nsfs: add ioctl to get a parent namespace Andrey Vagin
2016-07-14 18:20 ` [PATCH 5/5] tools/testing: add a test to check nsfs ioctl-s Andrey Vagin
2016-07-14 22:02 ` [PATCH 0/5 RFC] Add an interface to discover relationships between namespaces Andrey Vagin
2016-07-15 2:12 ` [PATCH 1/5] namespaces: move user_ns into ns_common Andrey Vagin
2016-07-15 2:12 ` [PATCH 2/5] kernel: add a helper to get an owning user namespace for a namespace Andrey Vagin
2016-07-24 5:03 ` Eric W. Biederman
2016-07-24 6:37 ` Andrew Vagin
2016-07-24 14:30 ` Eric W. Biederman
2016-07-24 17:05 ` W. Trevor King
2016-07-24 16:54 ` W. Trevor King
2016-07-15 2:12 ` [PATCH 3/5] nsfs: add ioctl to get an owning user namespace for ns file descriptor Andrey Vagin
2016-07-15 2:12 ` [PATCH 4/5] nsfs: add ioctl to get a parent namespace Andrey Vagin
2016-07-24 5:07 ` Eric W. Biederman
2016-07-15 2:12 ` [PATCH 5/5] tools/testing: add a test to check nsfs ioctl-s Andrey Vagin
2016-07-16 8:21 ` [PATCH 1/5] namespaces: move user_ns into ns_common kbuild test robot
2016-07-23 23:07 ` kbuild test robot
2016-07-24 5:00 ` Eric W. Biederman
2016-07-24 5:54 ` Andrew Vagin
[not found] ` <87k2gbmy02.fsf-JOvCrm2gF+uungPnsOpG7nhyD016LWXt@public.gmane.org>
2016-07-24 5:54 ` Andrew Vagin
2016-07-24 5:54 ` Andrew Vagin
2016-07-24 5:54 ` Andrew Vagin
2016-07-24 5:10 ` [PATCH 0/5 RFC] Add an interface to discover relationships between namespaces Eric W. Biederman
2016-07-26 2:07 ` Andrew Vagin
2016-07-21 14:41 ` Michael Kerrisk (man-pages)
2016-07-21 21:06 ` Andrew Vagin
[not found] ` <20160721210650.GA10989-1ViLX0X+lBJGNQ1M2rI3KwRV3xvJKrda@public.gmane.org>
2016-07-22 6:48 ` Michael Kerrisk (man-pages)
2016-07-22 18:25 ` Andrey Vagin
2016-07-25 11:47 ` Michael Kerrisk (man-pages)
2016-07-25 13:18 ` Eric W. Biederman
2016-07-25 14:46 ` Michael Kerrisk (man-pages)
2016-07-25 14:54 ` Serge E. Hallyn
2016-07-25 15:17 ` Eric W. Biederman
2016-07-25 14:59 ` Eric W. Biederman
2016-07-26 2:54 ` Andrew Vagin
2016-07-26 8:03 ` Michael Kerrisk (man-pages)
2016-07-26 18:25 ` Andrew Vagin
2016-07-26 18:32 ` W. Trevor King
2016-07-26 19:11 ` Andrew Vagin
2016-07-26 19:17 ` Michael Kerrisk (man-pages)
2016-07-26 20:39 ` Andrew Vagin
2016-07-28 10:45 ` Michael Kerrisk (man-pages)
2016-07-28 12:56 ` Eric W. Biederman
2016-07-28 19:00 ` Michael Kerrisk (man-pages)
2016-07-29 18:05 ` Eric W. Biederman
2016-07-31 21:31 ` Michael Kerrisk (man-pages)
2016-08-01 23:01 ` Andrew Vagin
2016-07-26 19:38 ` Eric W. Biederman
2016-07-23 21:14 ` W. Trevor King
2016-07-23 21:38 ` James Bottomley
2016-07-23 21:58 ` W. Trevor King
2016-07-23 21:56 ` Eric W. Biederman
2016-07-23 22:34 ` W. Trevor King [this message]
2016-07-24 4:51 ` Eric W. Biederman
2016-08-01 18:20 ` Alban Crequy
2016-08-01 23:32 ` Andrew Vagin
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=20160723223448.GP24913@odin.tremily.us \
--to=wking@tremily.us \
--cc=James.Bottomley@HansenPartnership.com \
--cc=avagin@openvz.org \
--cc=containers@lists.linux-foundation.org \
--cc=criu@openvz.org \
--cc=ebiederm@xmission.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mtk.manpages@gmail.com \
--cc=serge.hallyn@canonical.com \
--cc=viro@zeniv.linux.org.uk \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).