Re: Audit Parsing Library Requirements
On Friday 10 March 2006 14:53, Klaus Weidner wrote:
- audit records that contain the same field name twice for different
purposes in a single record. I think this happens in a couple of places
where uid or something like that is re-used. My preference would be to
consider this a bug in the audit generation that needs fixing, instead
of having the parser handle it.
I'm ambivalent about this. The current behavior is to favor the uid in the
message instead of the kernel supplied one. For example, root change bob's
account password. search for uid=bob will hit on the password change event
since bob's account is what's being manipulated.
(As a side note, any remaining tag names containing spaces should
also be
fixed...)
Sure...point them out.
- multiple related audit records for a single event that contain
several
instances of the same tag, for example a syscall such as rename() that
generates multiple path tags for source and destination. I'm not sure
how those get handled, is that what this is intended for?
Could be. Or maybe you just want a certain field and that's all. In this case,
you set the search item the first time and then step through the records with
auparse_find_field_next.
auparse_find_field("auid");
while (auparse_next_event()) {
while (auparse_next_record()) {
while (auparse_find_field_next()) {
do-something
}
}
}
BTW, without this function, you wouldn't have a way to verify that one and
only one field type is emitted for each record if we decide to cleanup the
messages.
Does the auparse library handle merging of related records for
single
events, or is that left for higher level code?
The library would group the records into events and let you step through them.
while (auparse_next_event()) {
while (auparse_next_record()) {
while (auparse_next_field()) {
do-something
}
}
}
-Steve