netdev - Re: [patch net-next] vlan: Don't allow vlan devices to change network namespaces.

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: <535A37BE.7020203@huawei.com>
Date:	Fri, 25 Apr 2014 18:23:58 +0800
From:	chenweilong <chenweilong@...wei.com>
To:	<nicolas.dichtel@...nd.com>, Michal Kubecek <mkubecek@...e.cz>
CC:	Eric Dumazet <eric.dumazet@...il.com>, <kaber@...sh.net>,
	<davem@...emloft.net>, <netdev@...r.kernel.org>
Subject: Re: [patch net-next] vlan: Don't allow vlan devices to change network
 namespaces.

On 2014/4/24 21:21, Nicolas Dichtel wrote:
> Le 24/04/2014 14:41, chenweilong a écrit :
>> On 2014/4/24 19:32, chenweilong wrote:
>>> On 2014/4/24 13:47, Michal Kubecek wrote:
>>>> On Thu, Apr 24, 2014 at 08:59:51AM +0800, chenweilong wrote:
>>>>> On 2014/4/23 15:23, Nicolas Dichtel wrote:
>>>>>> Le 23/04/2014 04:40, chenweilong a écrit :
>>>>>>> And, 2) is not safe, if someone forgets to move eth1, eth1.5 will not work, making
>>>>>>> things complex.
>>>>>> We have to fix this case, because it is a valid use case to have eth1.5 in net0
>>>>>> and eth1 in another ns.
>>>>>>
>>>>> eth1.5 can receive and send packets in net0, the problem is you can't add a new eth1.5
>>>>> in old ns, report 'error: File exists'.
>>>>
>>>> And this is correct, as far as I can tell. If it was possible, which of
>>>> the two interfaces would receive VLAN tagged packets with VID 5 coming
>>>> to eth1?
>>>>
>>>>                                                           Michal Kubecek
>>>>
>>>>
>>>>
>>> If eth1 and eth1.5 can work in different ns,
>>> my fist test(move eth1 first,and then eth1.5) should be success,
>>> but it failed, if eth1 was moved to other ns, all related vlans were unregisted.
>>> Strangely, if I move eth1.5 to net0, then move eth1 to net0, and then
>>> move eth1 to net1, eth1.5 is still there!
>>> It is a bug?
>> Find at last it's a behavior of SUSE's udevd , not the kernel.
>> When move eth1 to net0, udevd call /sbin/ifdown to down eth1
>> and then ifdown eth1.5, and then ifdown-802.1q eth1.5 and then
>> vconfig rem eth1.5!
>>
>> Thanks everybody!
>>>
>>> I agree with you there should be one interface tagged with VID 5 in the system.
>>> But I think the network namespaces are independent, vlan port and its VID interfaces
>>> spread in different ns break the rule.
> VID are unique per interface, for example eth0 can only have one VID 5.
> Even if eth1.5 stands in another netns, it is still "connected" to eth0.
> 
> I agree that network namespaces are independent, but there are mechanism to
> connect them between each other or to connect these netns to a "physical"
> network even if you don't have a NIC for each netns on your system. For
> example, IP tunnels (ipip, sit, ip6_tunnels) allow to have encapsulation
> addresses in one netns and the netdevice in another netns:
> 
> ip netns add ns1
> ip netns exec ns1 ip link set lo up
> 
> ip link add ipip1 type ipip remote 10.16.0.121 local 10.16.0.249
> ip link set ipip1 netns ns1
> ip netns exec ns1 ip link set ipip1 up
> ip netns exec ns1 ip addr add dev ipip1 192.168.2.123 remote 192.168.2.121
> 
> vlan may also provide this kind of mechanism.
> 
> Regards,
> Nicolas
> 
> 
Agree,

Thanks!

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