[lkml]   [2016]   [Jul]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 0/5 RFC] Add an interface to discover relationships between namespaces
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
> 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.


[unhandled content-type:application/pgp-signature]
 \ /
  Last update: 2016-07-24 00:21    [W:0.190 / U:0.820 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site