netdev - Re: [PATCH RFC] IPv6: RTM_GETROUTE NLM_F_MATCH handled as stated in RFC 3549

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: <20120103.151619.1382800390097680631.davem@davemloft.net>
Date:	Tue, 03 Jan 2012 15:16:19 -0500 (EST)
From:	David Miller <davem@...emloft.net>
To:	matti.vaittinen@....com
Cc:	netdev@...r.kernel.org
Subject: Re: [PATCH RFC] IPv6: RTM_GETROUTE NLM_F_MATCH handled as stated
 in RFC 3549

From: Matti Vaittinen <matti.vaittinen@....com>
Date: Wed, 28 Dec 2011 16:01:55 +0200

> This patch makes ipv6 module to return only routes which match 
> attributes / filled fields in RTM_GETROUTE, if NLM_F_MATCH is 
> specified and NLM_F_ROOT is not. This patch has not been tested, 
> and is meant more to be for visualization of what I thought of doing.
> If the NLM_F_MATCH support is considered to be good idea, then I 
> will check this more thoroughly and send another patch.
> 
> I assume this would not break *many* existing userspace applications, 
> since specifying NLM_F_MATCH (especially with no NLM_F_ROOT) sounds 
> pretty stupid - if no entries should be filtered.
> 
> I checked iproute2, and it uses NLM_F_DUMP and does filtering entries 
> in userspace - thus it is not affected. 
> 
> I guess this same idea could be brought in RTM_GETADDR and RTM_GETLINK 
> too? Maybe also on IPv4 side? 

The problem is that you can't avoid writing the user level filters
even if we add this behavior now.

Any tool which wants to work on every single Linux system out there
right now has to accomodate the case where NLM_F_MATCH isn't done by
the kernel.  It will take several years before this would be widely
deployed even if it went in right now.

This means applications are not simplified at all, in fact they become
more complex, since they have to accomodate not just one but two
possible cases.

Specifying this behavior in RFC 3549 is pretty pointless, given the
existing situation.

So the value proposition of adding this change doesn't add up to me.

I'm therefore not inclined to apply a patch like this, sorry.  And even
if I was, I'd ask that ipv4 get it first or at the same time.

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