linux-kernel - Re: [PATCH net-next v1 3/5] ipv4: enable IFA_IF_NETNSID for RTM

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 4 Sep 2018 08:50:06 +0200
From:   Jiri Benc <jbenc@...hat.com>
To:     David Ahern <dsahern@...il.com>
Cc:     Christian Brauner <christian@...uner.io>, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org, davem@...emloft.net,
        kuznet@....inr.ac.ru, yoshfuji@...ux-ipv6.org,
        pombredanne@...b.com, kstewart@...uxfoundation.org,
        gregkh@...uxfoundation.org, fw@...len.de, ktkhai@...tuozzo.com,
        lucien.xin@...il.com, jakub.kicinski@...ronome.com,
        nicolas.dichtel@...nd.com
Subject: Re: [PATCH net-next v1 3/5] ipv4: enable IFA_IF_NETNSID for
 RTM_GETADDR

On Mon, 3 Sep 2018 21:11:30 -0600, David Ahern wrote:
> Can only use it once per message type, but NLM_F_DUMP_FILTERED is a flag
> that can be set to explicitly say the request is filtered as requested.

The problem is that NLM_F_DUMP_FILTERED is too coarse. There's no way
to determine whether the netnsid was honored or whether it was not but
other filtering took effect.

This is a general problem with netlink: unknown attributes are ignored.
We need a way to detect that certain attribute was understood by the
kernel or was not. And it needs to work retroactively, i.e. the
application has to be able to determine the currently running kernel
does not support the feature (because it's too old).

That's why we return back the attribute in responses to a request with
IFLA_IF_NETNSID present and why we should do the same for
IFA_IF_NETNSID.

> See 21fdd092acc7e. I would like to see other filters added for addresses
> in the same release this gets used. The only one that comes to mind for
> addresses is to only return addresses for devices with master device
> index N (same intent as 21fdd092acc7e for neighbors).

I also question the statement that IFA_F_NETNSID is a filter: my
understanding of "filter" is something that limits the output to a
certain subset. I.e., unfiltered results always contain everything that
is in a filtered result. While with IFA_F_NETNSID, we get a completely
different set of data. Does that really constitute a filter? Note that
we can still filter in the target netns.

Thanks,

 Jiri