lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 28 Feb 2008 12:31:23 -0700
From: (Eric W. Biederman)
To:	Pavel Emelyanov <>
Cc:	Andrew Morton <>,
	David Miller <>,
	Alexey Dobriyan <>,
	Linux Netdev List <>,
	Linux Kernel Mailing List <>
Subject: Re: [PATCH 0/2] Fix /proc/net in presence of net namespaces

Pavel Emelyanov <> writes:

> Current /proc/net is done with so called "shadows", but current
> implementation is broken and has little chances to get fixed.
> The problem is that dentries subtree of /proc/net directory has
> fancy revalidation rules to make processes living in different
> net namespaces see different entries in /proc/net subtree, but
> currently, tasks see in the /proc/net subdir the contents of any
> other namespace, depending on who opened the file first.
> The proposed fix is to turn /proc/net into a symlink, which behaves
> similar to /proc/self link - it points to .netns/<id> directory 
> where the <id> is the id of net namespace, current task lives in.
> # ls -l /proc/net
> lrwxrwxrwx  1 root root 8 Feb 28 18:38 /proc/net -> .netns/0
> The /proc/.netns dir contains subtrees for all the namespaces in 
> the system:
> # ls -l /proc/.netns/
> total 0
> dr-xr-xr-x  5 root root 0 Feb 28 18:39 0
> dr-xr-xr-x  3 root root 0 Feb 28 18:39 1
> To provide some security each /proc/.netns/<id> directory allows
> access to tasks that live in the owning namespace only (with the
> exception, that init_net tasks can see everything).

Nack.  Yet another global set of ids that require us to implement another
namespace looks like the wrong way to go.

Can you try this approach by capturing a struct pid instead of an id
in a new global namespace? 

In particular the pid of the process that creates the pid namespace.
Like we do with setsid.

I think the implementation difficulty should be about the same, but
it will allow us something that works cleanly in the cases of
migration and nested namespaces.  As well as not adding an unnecessary
special case with init_net and visibility.

To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to
More majordomo info at

Powered by blists - more mailing lists