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

Paul Moore
2014-10-22T20:44:05Z

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