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

Steve Grubb
2013-07-09T18:30:09Z

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