On 2018-09-18 8:57 a.m., Johannes Berg wrote:
On Tue, 2018-09-18 at 08:55 -0400, Jamal Hadi Salim wrote:
Execute permission kind of thing? i.e if i understood you correctly
if acl is "rwx" then attribute can only be written to (or read from) if
the "thing executing" is complete
But it's not an attribute that you're executing, it's some kind of
command, and then you get the return value of that command in that
attribute?
Say you want to scan for wifi networks - you trigger a scan, later you
get a notification giving you some data about the scan (let's say the
time it took) - there's no way you can set that time attribute.
Not very familiar with how wifi scan gets initiated. I am guessing
you issue some GET or SET to start a scan - and you get an async
response when it is complete (and it would include the time it took)?
Or maybe you get an immediate response and event notification later
and the time spent is in that notification?
I would still see that as a read-only attribute.
And the utility of "execute" bit is only in blocking another scan
from being initiated when one is in progress, if that is a desired
goal.
Note in most net devices stats can only be read but not written to
for example.
(NB: it doesn't work this way, we don't have that attribute now, but I
didn't want to pick a more complicated example)
What would the practical difference be though? Hopefully you wouldn't
have write-only attributes, and then NLA_REJECT is basically equivalent?
If ACL says "-w-" then reading should get explicit permission denied
code possibly with an extack which is more descriptive that reading
is not allowed.
Perhaps. But NLA_REJECT comes with an extack string to tell you, so ...
I dunno. I think we already bloated the policies too much by including
the validation_data pointer, and would hate to add more to that :-)
Your mileage may vary. NLA_REJECT may work acls offer more fine grained
controls.
cheers,
jamal
