From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Paris Subject: Re: [PATCH 1/7] audit: implement generic feature setting and retrieving Date: Tue, 09 Jul 2013 16:59:40 -0400 Message-ID: <1373403580.4051.20.camel@localhost> References: <1369411910-13777-1-git-send-email-eparis@redhat.com> <50865580.fuY1fV85TX@x2> <1373320507.2395.50.camel@dhcp137-13.rdu.redhat.com> <2159084.93XGNZxGYL@x2> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <2159084.93XGNZxGYL@x2> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Steve Grubb Cc: linux-audit@redhat.com List-Id: linux-audit@redhat.com On Tue, 2013-07-09 at 14:30 -0400, Steve Grubb wrote: > > 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? No. The new interface is written to be on/off locked/unlock The get/set interface could be extended to allow for this. We'd have to grow the size of struct audit_status with a new __u32. Kernel space would have to 0 out the struct and overwrite it with what it got from userspace. Userspace would just have to ignore the additional info from a read... I agree, a version field is useful.