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

2014-08-22 Thread Steve Grubb
Hello, Just spent some time debugging auditctl, it was doing something I thought was weird. I tracked it down to this patch, see below for commentary... 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

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

2013-11-02 Thread Eric Paris
On Sat, 2013-11-02 at 03:26 -0400, Richard Guy Briggs wrote: > On Fri, May 24, 2013 at 12:11:44PM -0400, 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

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

2013-11-02 Thread Richard Guy Briggs
On Fri, May 24, 2013 at 12:11:44PM -0400, 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 > structure shou

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

2013-07-09 Thread Steve Grubb
On Friday, May 24, 2013 12:11:44 PM Eric Paris wrote: > +static void audit_log_feature_change(int which, u32 old_feature, u32 > new_feature, + u32 old_lock, u32 > new_lock, int res) > +{ > + struct audit_buffer *ab; > + > + ab = audit_log_start(NULL, GFP

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

2013-07-09 Thread Eric Paris
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

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

2013-07-09 Thread Steve Grubb
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 wh

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

2013-07-08 Thread William Roberts
On Mon, Jul 8, 2013 at 2:55 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

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

2013-07-08 Thread Eric Paris
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 enabl

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

2013-07-08 Thread Steve Grubb
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 be

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

2013-05-30 Thread Richard Guy Briggs
On Fri, May 24, 2013 at 12:11:44PM -0400, 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 > structure shou

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

2013-05-24 Thread William Roberts
A couple other comments I missed before: #define AUDIT_FEATURE_TO_MASK(x) (1 << ((x) & 31)) /* mask for __u32 */ Why &31 --> if someone adds more than 5 things, they will git dropped out... #define AUDIT_FEATURE_TO_MASK(x) (1 << ((x) & (~(__u32)0))) /* mask for __u32 */ something

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

2013-05-24 Thread William Roberts
Looking through the patch, these are my thoughts: I like that my "splitlog" patch shrunk a lot, way easier. I like that. It also proves something like this is the correct direction. Shouldn't audit_set_feature() check the version number, granted it doesn't mater now, but shouldn't their be a: i

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

2013-05-24 Thread Eric Paris
On Fri, 2013-05-24 at 12:11 -0400, 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 > structure should be a

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

2013-05-24 Thread Eric Paris
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 structure should be able to grow in the future while maintaining forward and backw