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: <CACP96tTRQqvQM6UTuqtVonZJW3LaHkBZkkpH+zCZa=GjHAEy+Q@mail.gmail.com>
Date:	Tue, 13 May 2014 06:49:46 -0400
From:	sowmini varadhan <sowmini05@...il.com>
To:	Lorenzo Colitti <lorenzo@...gle.com>
Cc:	netdev <netdev@...r.kernel.org>, JP Abgrall <jpa@...gle.com>,
	David Miller <davem@...emloft.net>,
	Julian Anastasov <ja@....bg>,
	Hannes Frederic Sowa <hannes@...essinduktion.org>
Subject: Re: [PATCH 0/3] Make mark-based routing work better with multiple
 separate networks.

On Mon, May 12, 2014 at 6:53 PM, Lorenzo Colitti <lorenzo@...gle.com> wrote:
> On Tue, May 13, 2014 at 6:09 AM, sowmini varadhan <sowmini05@...il.com> wrote:
>> http://lwn.net/Articles/407495/, a single
>> process should be able to open sockes in different namespaces.
>
> Other things that you can't do with namespaces are have the same physical
> interface (and the same IP address?) in two different namespaces, or
> have the same listening socket in two different namespaces. Namespaces
> are not a panacea.'

So this thread got unintentionally cut off by my not selecting Reply-All
in the google gui.

But to summarize a couple of private exchanges between Lorenzo and
me, it still appears to me that the use-case here is what routers
consider a "VRF". Thus it makes sense to add code (if/as needed)
to fix the VRF support in linux, rather than adding yet-another-one-off
feature with socket marking.

Specifically addressing the two issues raised above:
- yes, it is true that an interface can exist in only one netns at a time.
  But the same ip address can exist in multiple netns-es. If the
  app wants to listen to a proper-subset of networks that go in/out
  a single physical interface, you can use macvlan, and assign the
  macvlans to the desired netns.
- "same listening socket for multiple namespaces". Clearly that problem
  also exists for the socket-marks approach. But again this can actually
  be solved (for both netns and sock-marks) by having the application
  set up separate sockets for each netns (netns or whatever) of interest,
  and build an epoll fd over that set of sockets. No need for any kernel
  code for this.

  Or you can optimize this by building infra in the kernel to support the
  Wildcard ALL_VRFS notion. Or add even more code to support something
  less than ALL_VRFS.

My point is: what is the real networking construct that this use-case needs?
Isn't it what routers describe as the VRF? If yes, then shouldnt
we have one single way of supporting that in linux, instead of having
a little-bit-here and a little-bit-there?

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