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. James
Attachment:
signature.asc
Description: This is a digitally signed message part
