Audit Parsing Library Requirements

[Steve Grubb]

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