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

[LC Bruzenak <lenny@magitekltd.com>]

[-- Attachment #1.1: Type: text/plain, Size: 1309 bytes --]

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...

LCB

-- 
LC (Lenny) Bruzenak
lenny@magitekltd.com



[-- Attachment #1.2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 2193 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]