netdev - Re: [RFC PATCH net-next 0/5] netns: allow to identify peer netns

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