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]
Message-ID: <5562FFB0.40708@ahsoftware.de>
Date:	Mon, 25 May 2015 12:55:44 +0200
From:	Alexander Holler <holler@...oftware.de>
To:	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 25.05.2015 um 09:45 schrieb Nicolas Dichtel:
> Le 22/05/2015 22:50, Alexander Holler a écrit :

>> 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.
> This option is only for 'listening', ie spontaneous notifications from the
> kernel. It does nothing for request.

The problem is that you need informations about the affected interfaces. 
E.g. if you receive an NEWADDR or NEWROUTE for some interface (indicated 
by the index of the interface) in a(nother) namespace, how do you get 
informations about that interface, if not by a dump which includes the 
interfaces of these namespaces too? Without knowledge about the 
interface, these messages are not very usable. ;)

> Not sure to follow you. veth0 sits in the current netns (let's say
> init_net)
> and veth1 in netns1.
> So, when you dump veth0 in init_net, its link-netnsid is set to the id of
> netns1 in init_net. And when you dump veth1 in netns1, it's link-netnsid
> is set
> to the id of init_net in netns1.

I've misunderstood the meaning of IFLA_LINK_NETNSID. I thought it 
indicates the namespace an interface lives in, but it indicates the 
namespace it is linked too.

I've also thought that the NETNSID is a global unique identifier of a 
namespace, which seems to be wrong too. While I still not have read 
through all the sources, the other comments are suggesting that the NSID 
is just an ID which is unique only in one namespace, or in other words, 
every namespace has its own set of nsids. I'm not sure if I'm now right 
with that assumption, but that's what I now think after the responses to 
my mail. ;)

So to conclude, I've now scheduled support for namespaces to a far later 
point. It doesn't seem to be as easy as I've thought after having read 
the introductory mail of your patch series. ;)

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ