lists.openwall.net   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  linux-hardening  linux-cve-announce  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:	Wed, 18 May 2011 16:03:03 +0300
From:	Alexey Dobriyan <adobriyan@...il.com>
To:	David Lamparter <equinox@...c24.net>
Cc:	"Eric W. Biederman" <ebiederm@...ssion.com>,
	linux-arch@...r.kernel.org, linux-kernel@...r.kernel.org,
	netdev@...r.kernel.org, linux-fsdevel@...r.kernel.org,
	jamal <hadi@...erus.ca>, Daniel Lezcano <daniel.lezcano@...e.fr>,
	Linux Containers <containers@...ts.osdl.org>,
	Renato Westphal <renatowestphal@...il.com>
Subject: Re: Identifying network namespaces (was: Network namespace
 manipulation with file descriptors)

On Wed, May 18, 2011 at 3:43 PM, David Lamparter <equinox@...c24.net> wrote:
> -   processes cannot easily be cross referenced with each other
>
>  in the case of user space stuff running astray - like management
>  software crashing, routing daemons screwing up, etc. - it becomes
>  fairly difficult to shut down a network namespace (or even reaquire
>  physical devices that have been reassigned)

It shutdowns itself when last process using netns disappeares,
so if you kill your routing daemons you should be fine.
Physical netdevices are moved to init_net.

> -   namespaces cannot adequately be identified to the user
>
>  for debugging, some kernel messages become useless. most prominently,
>  "unregister_netdevice: waiting for lo to become free. Usage count = 123"
>  could certainly use some clarification, *which* lo is meant...

There is no "netns %p" or something, because right now the only unique
netns identifier is kernel pointer (which better not be exposed to userspace).
Printing such thing would be quite useless since it's not printed
at netns creation.

> So, considering this set of premises (feedback welcome) I looked for
> some suitable means of identification. I discarded going for any process
> identifiers since Eric's patches allow for network namespaces without
> any process holding a reference, using bind mounts instead.

If anything it should be netns->id, /proc/*/netns outputting id
where id is not derived from kernel pointer.

> Solution?
> =========

What a hack! :-)
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists