netdev - Re: [patch net-2.6.25 1/2][NETNS] net: Modify the neighbour table code so it handles multiple network namespaces

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>] [day] [month] [year] [list]

Date:	Mon, 24 Dec 2007 15:56:22 -0800 (PST)
From:	David Miller <davem@...emloft.net>
To:	ebiederm@...ssion.com
Cc:	netdev@...r.kernel.org, den@...nvz.org, benjamin.thery@...l.net
Subject: Re: [patch net-2.6.25 1/2][NETNS] net: Modify the neighbour table
 code so it handles multiple network namespaces

From: Eric.W.Biederman" <ebiederm@...ssion.com>"@fr.ibm.com
Date: Fri, 21 Dec 2007 14:02:24 +0100

> I'm actually surprised at how much was involved.  At first glance it appears
> that the neighbour table data structures are already split by network device
> so all that should be needed is to modify the user interface commands
> to filter the set of neighbours by the network namespace of their devices.
> 
> However a couple things turned up while I was reading through the code.
> The proxy neighbour table allows entries with no network device, and
> the neighbour parms are per network device (except for the defaults)
> so they now need a per network namespace default.
> 
> So I updated the two structures (which surprised me) with their very
> own network namespace parameter.  Updated the relevant lookup and
> destroy routines with a network namespace parameter and modified
> the code that interacts with users to filter out neighbour
> table entries for devices of other namespaces.
> 
> I'm a little concerned that we can modify and display the global
> table configuration and from all network namespaces.  But
> this appears good enough for now.
> 
> I keep thinking modifying the neighbour table to have per network
> namespace instances of each table type would should be cleaner.  The
> hash table is already dynamically sized so there are it is not a limiter.
> The default parameter would be straight forward to take care of.  However
> when I look at the how the network table is built and used I still find
> some assumptions that there is only a single neighbour table for each
> type of table in the kernel.  The netlink operations, neigh_seq_start,
> the non-core network users that call neigh_lookup.  So while it might
> be doable it would require more refactoring than my current approach
> of just doing a little extra filtering in the code.
> 
> Signed-off-by: Eric W. Biederman <ebiederm@...ssion.com>
> Signed-off-by: Daniel Lezcano <dlezcano@...ibm.com>

Applied, thanks.
--
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