Re: [PATCH 1/7] audit: implement generic feature setting and retrieving

[Steve Grubb <sgrubb@redhat.com>]

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