Re: [PATCH 0/5 RFC] Add an interface to discover relationships between namespaces
From: James Bottomley
Date: Sat Jul 23 2016 - 17:39:17 EST
On Sat, 2016-07-23 at 14:14 -0700, W. Trevor King wrote:
> On Thu, Jul 14, 2016 at 11:20:14AM -0700, Andrey Vagin wrote:
> > Pid and user namepaces are hierarchical. There is no way to
> > discover parent-child relationships too.
> It bothers me that network namespaces are not hierarchical too ;).
Well, there's a reason for that: mapping namespaces need to be be
hierarchical because the mapping may be remapped; The initial point for
creating a new namespace is the mapped endpoint of the old one. Label
based namespaces don't really have any need to be.
> 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
> So the initial network namespace (the head of net_namespace_list?) is
> special . 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.
Description: This is a digitally signed message part