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] [day] [month] [year] [list]

Message-ID: <53C53B7A.5000909@6wind.com>
Date:	Tue, 15 Jul 2014 16:32:26 +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.
Maybe there is no other solution. Network people uses netns to implement
"virtual router", ie only network namespaces are used. Userland daemons
manage a set of netns. These daemons need to be able to identify a peer netns
when netlink messages from kernel are parsed. For now, these netlink messages
are incomplete and contain information that cannot be interpreted (like the
IFLA_LINK ifindex).

Can you give me more details about the "process migration"? How does it work
when you have a veth tunnel between two netns?

>
> Which means this is a major mess that really isn't going to work because
> it generates more problems than it solves.
It's just a netns inside another netns, or to be easier to figure out, one or
more virtual router inside a netns ;-)

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