From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve Grubb Subject: Re: [PATCH 1/7] audit: implement generic feature setting and retrieving Date: Tue, 09 Jul 2013 14:30:09 -0400 Message-ID: <2159084.93XGNZxGYL@x2> References: <1369411910-13777-1-git-send-email-eparis@redhat.com> <50865580.fuY1fV85TX@x2> <1373320507.2395.50.camel@dhcp137-13.rdu.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1373320507.2395.50.camel@dhcp137-13.rdu.redhat.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Eric Paris Cc: linux-audit@redhat.com List-Id: linux-audit@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