Audit Parsing Library Requirements

Michael C Thompson mcthomps at us.ibm.com
Mon Mar 13 16:06:03 UTC 2006


Steve Grubb <sgrubb at redhat.com> wrote on 03/13/2006 09:14:22 AM:

> On Monday 13 March 2006 09:35, Michael C Thompson wrote:
> > I know this is not likely to change, but is there a reason why we 
don't
> > have a common delimiter?
> 
> Personally, I think its a bad idea since it makes the text "darker". 
Spaces 
> make it lighter and more pleasing to the eye. Its too later to make 
these 
> kind of changes.

Wow, what I wrote is not what I mean. I should say that I am _not_ in 
favor of commas, I was trying to point out that spaces between fields (and 
only spaces), should be the way to go since its the most common form in 
our records and should therefore be made the only form for consistancy - 
not to mention all of the reasons you just listed. Sorry for not writing 
what I meant.

> 
> > Removing inconstancies in the records, such as using '_' in place of 
spaces
> > in field names and removing these commas, would seem like a good thing 
to
> > do, but before anyone does that work, will making that change be 
acceptable
> > from a code point of view?
> 
> I would like to fix inconsistencies, but I don't consider '_' to be an 
> inconsistency. I would be hesitant to make any other changes besides 
> normalizing records. Its unnecessary and unwanted.

Again, I was not clear, although when I wrote this, I thought I was. I was 
saying I am in favor of chaning field names, such as "login uid", and 
replacing them with "login_uid". Amazing how much meaning can be lost 
between the reader and the writer. Normalizing records is good!

> 
> > Although it is clear from the code example (and I am sure this is not
> > going to be the final version of the document, it would probably be 
nice
> > to mention that auparse will, when not using auparse_next_event, will 
be
> > parsing the record that was found (and is current being pointed to) by
> > ausearch_* functions, for example.
> 
> But this is not true.

It isn't? From the code example that I read, although it does not have any 
documentation comments with it, leads me to believe my understanding to be 
correct. btw, you forgot to free your memory in that example! See the next 
comment for more.

> 
> > Your comment in the above, "without regard to any search options that 
may be
> > in effect", is somewhat befuddling on this point.
> 
> OK, you put in a search for uid=500. ausearch will find events that have 
a 
> match. You should call ausearch functions to walk these events. So, for 
> example, the cursor goes to event 150 on first call, then event 200 next 

> call. If you auparse, then it will go to the next event which could be 
201. 
> 
> This is all common database techniques. One is based off an index and 
the 
> other is sequential access.

OK, we've got a serious breakdown in communication here. Yes, I understand 
that ausearch_next_event will get you to the next event that matches your 
criteria. And I also understand that auPARSE_next_event will get you to 
the next event that falls in chronologial order (in terms of serial number 
or time stamp, whatever) and that is _not_ subject to any specified search 
criteria. However, my sole point was it would be good to state clearly 
that all other auparse_* functions, which concern themselves with parsing 
of records and fields, will do so based on the current event they are at, 
whether you got to it through an ausearch_next_event call or an 
auparse_next_event call.

Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/linux-audit/attachments/20060313/b4f378e3/attachment.htm>


More information about the Linux-audit mailing list