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

Message-ID: <1325658265.7008.4.camel@hakki>
Date:	Wed, 04 Jan 2012 08:24:25 +0200
From:	Matti Vaittinen <matti.vaittinen@....com>
To:	ext David Miller <davem@...emloft.net>
Cc:	netdev@...r.kernel.org
Subject: Re: [PATCH RFC] IPv6: RTM_GETROUTE NLM_F_MATCH handled as stated in
 RFC 3549

On Tue, 2012-01-03 at 15:16 -0500, ext David Miller wrote:
> 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.

I can't argue. Like Metallica sang, "Sad but true".

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

No need to be sorry. I guess I can live with this ;) Thanks for closing
the case.

--Matti


-- 
Matti Vaittinen
+358 504863070
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Told a UDP joke the other night...
...but I'm not sure everyone got it...
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--
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