Re: [PATCH 1/7] audit: implement generic feature setting and retrieving
On Monday, July 08, 2013 05:55:07 PM Eric Paris wrote:
On Mon, 2013-07-08 at 16:28 -0400, Steve Grubb wrote:
> On Friday, May 24, 2013 12:11:44 PM Eric Paris wrote:
> > The audit_status structure was not designed with extensibility in mind.
> > Define a new AUDIT_SET_FEATURE message type which takes a new structure
> > of bits where things can be enabled/disabled/locked one at a time.
>
> This changes how we have been doing things. The way that the audit system
> settings have been done is to use the AUDIT_SET and AUDIT_GET commands. It
> takes a bit map as the function to perform. We have only used 5 of the 32
> bits.
>
> Do we really need another of the same thing?
It's not the same thing. This is an interface designed for options
which have 4 states. On/Off and Locked/Unlocked. It is certainly the
right solution for that problem if we want to solve it generically.
(look at what it did to the other code who wanted an on/off option)
AUDIT_SET/GET was designed around setting a kernel variable to a single
value. It does an ok job at this (although I'd argue that there could
be a better design here as well, but we have this, so we live with it.)
It certainly does not form naturally to the 4 states of the new
interface.
I did some more digging. I guess the GET/SET interface is limited. Setting
values could be done by reusing one of the places in the struct, but then
getting the values would be a problem.
So, how is user space supposed to detect that the kernel supports this
interface? What I have needed for years is a way to ask the kernel what
features it currently contains. For example, if you try to use interfield
comparisons and the kernel doesn't support it, I get an EINVAL and bounce that
to the user. What would be better is if I could ask the kernel what features
it contains and then I can not send the interfield comparison but output a
message saying the current kernel does not support this feature.
I can certainly shoehorn a 4 state interface into AUDIT_SET/GET.
Does the new interface support more than 4 a state variable? Suppose we need
to set a number value like 8192, will it do that?
-Steve