netdev - Re: [PATCH net-next v2 0/7] netns: ease netlink use with a lot of 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:	Fri, 22 May 2015 14:04:29 -0700
From:	Cong Wang <cwang@...pensource.com>
To:	Alexander Holler <holler@...oftware.de>
Cc:	Nicolas Dichtel <nicolas.dichtel@...nd.com>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	netdev <netdev@...r.kernel.org>, Thomas Graf <tgraf@...g.ch>,
	David Miller <davem@...emloft.net>
Subject: Re: [PATCH net-next v2 0/7] netns: ease netlink use with a lot of netns

On Fri, May 22, 2015 at 1:50 PM, Alexander Holler <holler@...oftware.de> wrote:
> Am 08.05.2015 um 14:02 schrieb Eric W. Biederman:
>>
>>
>> So I am dense.  I have read through the patches and I don't see where
>> you tag packets from other network namespaces with a network namespace
>> id.
>
>
> Me too,
>
> I've recently written a little tool called snetmanmon (source is
> available at github) to monitor and handle network related events
> by using rtnetlink.
>
> Having seen this patch series (thanks!), I've played with it.
>
> I've applied the patch series to v4.1-rc4.
>
> Maybe I'm using or holding it wrong, but I've some comments.
>
> First I think if NETLINK_LISTEN_ALL_NSID is enabled, a dump
> of the interfaces through RTM_GETLINK together with NLM_F_DUMP and
> NLM_F_REQUEST should return all interfaces of all reachable namespaces.
>
> Next, if NETLINK_LISTEN_ALL_NSID is enabled, I receive RTM_NEWLINK
> but without any indication of the namespace. E.g. if I do
>         ip netns add netns1
>         ip netns exec netns1 brctl addbr br0
> the RTM_NEWLINK for br0 (received in the root ns, not netns1) doesn't
> have the attribute IFLA_LINK_NETNSID.


Bridge doesn't have an underlying link, so no LINK_NETNSID. LINK_NETNSID
is only added when its underlying link is in a different netns.


>
> Same for the RTM_DELLINK msg if I call
>         ip netns exec netns1 brctl delbr br0
> afterwards. So both netlink messages are looking like br0 was
> created in the root ns.
>
> Another problem seems to be with veth devices. E.g. if I do
>         ip link add veth0 type veth peer name veth1
>         ip link set veth1 netns netns1
> I receive
>         RTM_NEWLINK for veth0 (no nsid)
>         RTM_NEWLINK for veth1 (no nsid)
>         RTM_DELLINK for veth1 (no nsid)
>         RTM_NEWLINK for veth1 (with nsid 0)
> That looks ok, except the missing RTM_NEWLINK for lo in netns1, which
> was created together with the namespace. But if I now request a dump,
> I get
>         RTM_NEWLINK for veth0 (with nsid 0)
> which looks like veth0 is part of nsid 0, and I get nothing for veth1.
> Of course, that vlan device might be part of nsid 0 too (as veth1),
> but its part named veth0 is not part of that namespace. So the
> IFLA_LINK_NETNSID attribute received with the RTM_NEWLINK for veth0 through
> the dump is misleading.

That is because the code tries to do "lazy" allocation for netnsid,
it defers it util the dumping, veth case is special here given how they pair,
I noticed the same "problem" (it doesn't have to be a bug) when I reviewed
the code, nobody cared. ;-/
--
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