[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <20190325091005.13574-1-johannes@sipsolutions.net>
Date: Mon, 25 Mar 2019 10:09:59 +0100
From: Johannes Berg <johannes@...solutions.net>
To: netdev@...r.kernel.org
Cc: David Ahern <dsa@...ulusnetworks.com>,
Pablo Neira Ayuso <pablo@...filter.org>
Subject: [RFC v3 0/6] netlink strict validation
Here's yet another respin. The big change since v2 is replacing the 2nd
patch by one that actually makes each validation bit configurable. The
old "strict" mode ends up setting 2 of the 5 bits, the new default (and
very strict) mode ends up with all 5 bits, of course.
This was inspired by a side discussion with Pablo, who still thinks that
accepting unknown attributes is a good thing. I obviously disagree, as
such attributes might modify behaviour and thus the user intent is no
longer guaranteed when ignored, but there are some rare cases where it
may be acceptable (such as a power-saving filter), though even in those
it's probably better to let the user know.
Anyway, inspired by that discussion I split out the NL_VALIDATE_UNSPEC
as that might actually be useful for even *old* code, seeing how you can
fill in all the policies, using NLA_MIN_LEN instead of NLA_UNSPEC for all
existing attributes, and then new attributes are forced to have a policy.
This is really the only change, but in order to do it users still need to
use the __nlmsg_parse(), __nla_parse() (and other double-underscore)
versions of the functions.
If Pablo (and Jamal to some extent, I think) end up convincing us that
the liberal validation is actually desired (sometimes), it may make some
sense to rename the *_deprecated() functions to something less shouting,
perhaps use *_old(). I just think that the default nla_parse() should be
defaulting to the stricter behaviour, and most people agree that the
default behaviour is desirable.
FWIW, Pablo also more or less agrees, but would like to have query
capabilities in the kernel first, so his userspace can figure out what
would be accepted w/o going to a "try this, remove if fails" dance.
I'll take a look at his old "netlink bus descriptions" patch to see
if that matches what I want to do wrt. this and see how we can merge
the two approaches.
johannes
Powered by blists - more mailing lists