Re: [RFC][PATCH] audit: log join and part events to the read-only multicast log socket

On Wednesday, October 22, 2014 04:06:47 PM Paul Moore wrote: > On Wednesday, October 22, 2014 01:56:13 PM Steve Grubb wrote: > > On Wednesday, October 22, 2014 11:28:46 AM Paul Moore wrote: > > > On Wednesday, October 22, 2014 10:25:35 AM Steve Grubb wrote: > > > > On Tuesday, October 21, 2014 06:30:24 PM Paul Moore wrote: > > > > > This is getting back to my earlier concerns/questions about field > > > > > ordering, or at the very least I'm going to hijack this conversation > > > > > and steer it towards field ordering ;) > > > > > > > > Field ordering is important. For example, suppose we decide to make > > > > ordering changes to the AUDIT_AVC record to bring it in line with > > > > current standards. Would anyone care? > > > > > > That is an interesting example record considering everyone recognizes it > > > to be an oddly formed, special case. > > > > But it illustrates the point. There are tools that depend on an ordering > > and format. There are more programs that just ausearch that needs to be > > considered if the fields change. For example, Someone could do things > > like this: > > > > retval = auparse_find_field(au, "auid"); > > retval = auparse_next_field(au); > > retval = auparse_next_field(au); > > retval = auparse_find_field(au, res"); > > > > Where, if the field ordering can't be guaranteed, the code becomes: > > > > retval = auparse_find_field(au, "auid"); > > retval = auparse_first_field(au); > > retval = auparse_find_field(au, "pid"); > > retval = auparse_first_field(au); > > retval = auparse_find_field(au, "uid"); > > retval = auparse_first_field(au); > > retval = auparse_find_field(au, res"); > > In my mind the latter code is more robust and preferable. Except you can have problems when the event is like this auid= pid= old uid= new uid= res= and yes there are places like that. The performance really is the main issue.

-Steve