netdev - Re: [PATCH 1/2] netlink: add NLA

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: <1537177132.2957.6.camel@sipsolutions.net>
Date:   Mon, 17 Sep 2018 11:38:52 +0200
From:   Johannes Berg <johannes@...solutions.net>
To:     Marcelo Ricardo Leitner <marcelo.leitner@...il.com>,
        Michal Kubecek <mkubecek@...e.cz>
Cc:     linux-wireless@...r.kernel.org, netdev@...r.kernel.org,
        jbenc@...hat.com
Subject: Re: [PATCH 1/2] netlink: add NLA_REJECT policy type

On Thu, 2018-09-13 at 18:58 -0300, Marcelo Ricardo Leitner wrote:

> > It would be easier and IMHO cleaner if I could simply list these "read
> > only attributes" with NLA_REJECT policy for "set" request.
> 
> Not that I'm against this. Point was fields that are considered output
> only today are probably being silently ignored, and we can't change
> them to be NLA_REJECT as it would break user applications. 

Indeed.

> Then we
> will have fields that are rejected, and those old that are not. In the
> long run, nearly all output fields would be marked as NLA_REJECT,
> okay.

Perhaps, yes, though I assume it would only really be true for new
families that bother to mark as such.

> Then I ask my first question again: why reject these? They are not
> hurting anything, are they?  It's different from your example I think.
> In there, the extra information which was ignored leads to a
> different behavior.

So in one case I was thinking of, there are some fields that simply
cannot be used for input, they're only used for output. But it may not
always be obvious to somebody using the API. Thus, I think it makes
sense to instruct the kernel to reject that, so that whoever gets
confused has immediate feedback that their usage is wrong. If we ignore
that, they may not realize their error immediately.

I think the ethtool case is similar: you can read and write some fields,
and only read others - but if you try to write the read-only fields
would you prefer to be told "sorry, this is not possible" vs. it being
silently ignored? I'd definitely prefer the former.

> Maybe it would be better to have NLA_IGNORE instead? </idea>

I don't think so, it doesn't give any feedback to the application author
that they're doing something wrong.

johannes