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 22:50:35 +0200
From:	Alexander Holler <holler@...oftware.de>
To:	Nicolas Dichtel <nicolas.dichtel@...nd.com>
CC:	"Eric W. Biederman" <ebiederm@...ssion.com>,
	netdev@...r.kernel.org, tgraf@...g.ch, davem@...emloft.net
Subject: Re: [PATCH net-next v2 0/7] netns: ease netlink use with a lot of
 netns

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.

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.

So it looks like either I missed something, I'm doing something wrong,
or there still is some work todo to make NETLINK_LISTEN_ALL_NSID work
like expected (or like my simple mind would expect it).

Thanks again for the patches, regards,

Alexander Holler

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