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]
Message-ID: <53B47DDE.7@6wind.com>
Date:	Wed, 02 Jul 2014 23:47:10 +0200
From:	Nicolas Dichtel <nicolas.dichtel@...nd.com>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
CC:	netdev@...r.kernel.org, davem@...emloft.net,
	stephen@...workplumber.org
Subject: Re: [RFC PATCH net-next 0/5] netns: allow to identify peer netns

Le 02/07/2014 22:09, Eric W. Biederman a écrit :
> Nicolas Dichtel <nicolas.dichtel@...nd.com> writes:
>
>> The goal of this serie is to be able to multicast netlink messages with an
>> attribute that identify a peer netns.
>> This is needed by the userland to interpret some informations contained in
>> netlink messages (like IFLA_LINK value, but also some other attributes in case
>> of x-netns netdevice (see also
>> http://thread.gmane.org/gmane.linux.network/315933/focus=316064)).
>>
>> Each network namespaces allocates its own ids for other netns (including
>> itself). The user can retrieve these ids via a new netlink messages, but only
>> if he has a FD which points to this netns. Dump is not implemented so that a
>> user cannot get the whole netns list.
>>
>> The goal of this RFC is mainly to validate the principle, ie patch 1/5 and 2/5.
>> Patch 3/5 and 4/5 shows an example of how to use these ids in rtnetlink
>> messages. And patch 5/5 shows that the netlink messages can be symetric between
>> a GET and a SET.
>
> This approach fundamentally breaks process migration, and calls for a
> namespace of namespaces.
Why does it call for a namespace of namespaces? Ids are different in each netns,
because each netns has its own list id.
Can you elaborate why it breaks the process migration?

Do you think that identifying a netns from another netns is fundamentally wrong?

Nicolas
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ