| 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
| ||
|
Message-ID: <CAMDZJNWpv89beaNvVvycJ5YqwcKYiFNuP_gYKz_QmsQ2roiRGw@mail.gmail.com> Date: Tue, 21 May 2019 13:53:04 +0800 From: Tonghao Zhang <xiangxia.m.yue@...il.com> To: David Miller <davem@...emloft.net> Cc: Linux Kernel Network Developers <netdev@...r.kernel.org> Subject: Re: [PATCH] net: vxlan: disallow removing to other namespace On Tue, May 21, 2019 at 7:53 AM David Miller <davem@...emloft.net> wrote: > > From: xiangxia.m.yue@...il.com > Date: Fri, 17 May 2019 19:42:23 -0700 > > > From: Tonghao Zhang <xiangxia.m.yue@...il.com> > > > > Don't allow to remove the vxlan device to other namesapce, > > because we maintain the data of vxlan net device on original > > net-namespace. > > > > $ ip netns add ns100 > > $ ip link add vxlan100 type vxlan dstport 4789 external > > $ ip link set dev vxlan100 netns ns100 > > $ ip netns exec ns100 ip link add vxlan200 type vxlan dstport 4789 external > > $ ip netns exec ns100 ip link > > ... > > vxlan200: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 > > vxlan100: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 > > > > And we should create it on new net-namespace, so disallow removing it. > > > > Signed-off-by: Tonghao Zhang <xiangxia.m.yue@...il.com> > > I don't understand this change at all. > > You keep saying "Remove" but I think you might mean simply "Move" because > the NETNS_LOCAL flag prevents moving not removing. Yes, should change "remove" to "move". > And why is it bad to allow vxlan devices to be moved between network > namespaces? What problem would it cause and can you guarantee that > you are not breaking an existing user? The problem is that we create one vxlan netdevice(e.g dstport 4789 and external), and move it to one net-namespace, and then we hope create one again(dstport 4789 and external) and move it to other net-namespace, but we can't create it. $ ip netns add ns100 $ ip link add vxlan100 type vxlan dstport 4789 external $ ip link set dev vxlan100 netns ns100 $ ip link add vxlan200 type vxlan dstport 4789 external RTNETLINK answers: File exists The better way is that we should create directly it in the net-namespace. To avoid confuse user, disallow moving it to other net-namespace. > I'm not applying this as-is.
Powered by blists - more mailing lists