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

[Paul Moore]

On Wednesday, October 22, 2014 03:34:24 PM LC Bruzenak wrote:
> On 10/22/2014 03:06 PM, Paul Moore wrote:
> >> > 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.
> 
> OK; I swear if you change this I'm going to parse EVERY field straight
> into a SQLite file first, since I'd have to go change code anyway.
> 
> :-)

 :)
 
> I have code which is based on the examples, from years back, which
> believe there is order. It can be changed if needed; rather not but could.
> I suspect there are others...

We haven't changed anything yet, but I strongly believe we need to do away 
with field ordering.  The good news is that if you explicitly search for the 
field instead of relying on a fixed order the code should be more robust and 
work either way. ;)

-- 
paul moore
security and virtualization @ redhat