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 23:46:47 +0200
From:	Alexander Holler <holler@...oftware.de>
To:	Cong Wang <cwang@...pensource.com>
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

Am 22.05.2015 um 23:29 schrieb Cong Wang:
> On Fri, May 22, 2015 at 2:12 PM, Alexander Holler <holler@...oftware.de> wrote:
>>>
>>> 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.
>>
>>
>> I'm using "link" similiar as interface. Maybe I've no idea what the
>> attribute LINK:NETSID really means, but I've understood it as the one
>> attribute which indicates the namespace an interface (or link), br0 in my
>> example, lives in.
>>
>
> It is for an underlying link for example: a veth pair is a link for each other,
> a tunnel device has a link to transmit packets.
>
> Bridge and bonding are master devices where "slaves" (or ports for bridge)
> can join.
>
> netns doesn't have a name or id by nature, we assign it a name by binding
> mount some /proc file, these LINK_NETNSID's are not absolutely unique either,
> just relatively.
>

Hmm. so making an inventory of all existing interfaces in all namespaces 
is either not really possible or ugly. If these IDs are not unique, what 
will I get when dumping the NETSID's? Sounds like I better forget that 
approach of using these IDs which means I would have to travel through 
the mounts and have to use GETLINK (with dump) from inside these 
namespaces, while having to identify the namespaces by their mount. That 
leads me to the problem how to find these mounts and ...

Not sure if I want to do that. It looked so easy to support namespaces 
but know it looks rather complicated.

Anyway, thanks a lot for the quick and fast responses and explanations.

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