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  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:	Thu, 30 Nov 2006 11:15:11 -0500
From:	Vlad Yasevich <>
To:	Daniel Lezcano <>
Cc:, "Eric W. Biederman" <>,
	Linux Containers <>,,
	Stephen Hemminger <>,
Subject: Re: [Devel] Re: Network virtualization/isolation

Daniel Lezcano wrote:
> Brian Haley wrote:
>> Eric W. Biederman wrote:
>>> I think for cases across network socket namespaces it should
>>> be a matter for the rules, to decide if the connection should
>>> happen and what error code to return if the connection does not
>>> happen.
>>> There is a potential in this to have an ambiguous case where two
>>> applications can be listening for connections on the same socket
>>> on the same port and both will allow the connection.  If that
>>> is the case I believe the proper definition is the first socket
>>> that we find that will accept the connection gets the connection.
> No. If you try to connect, the destination IP address is assigned to a
> network namespace. This network namespace is used to leave the listening
> socket ambiguity.
>> Wouldn't you want to catch this at bind() and/or configuration time and
>> fail?  Having overlapping namespaces/rules seems undesirable, since as
>> Herbert said, can get you "unexpected behaviour".
> Overlapping is not a problem, you can have several sockets binded on the
> same INADDR_ANY/port without ambiguity because the network namespace
> pointer is added as a new key for sockets lookup, (src addr, src port,
> dst addr, dst port, net ns pointer). The bind should not be forced to a
> specific address because you will not be able to connect via

So, all this leads to me ask, how to handle

For L2 it seems easy.  Each namespace gets a tagged lo device.
How do you propose to do it for L3, because disabling access to loopback is
not a valid option, IMO.

I agree that adding a namespace to the (using generic terms) TCB lookup 
solves the conflict issue.

To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to
More majordomo info at

Powered by blists - more mailing lists