On Tuesday 07 March 2006 13:53, John D. Ramsdell wrote:
From reading the manual page, and observing output, I conclude
ausearch
produces a sequence of events. Each event is a sequence of tables, one
table is specified on one line of output. A table is a sequence of
key-value pairs, and sometimes the value is missing.
The value should never be missing. Yes, each event is composed of individual
records which have fields. They are normalized (except for SE Linux AVC
messages).
If this description accurately reflects the structure of the output
of
ausearch, a simple callback-based programming interface is suggested.
For example, a consumer of the information could define a structure of
type struct audit_event_callback, and then pass a pointer to it to the
provider of audit data, in the following example, the gimme function.
We could have both a linked list representation and smart iterator. In the
latter case, you could have a next_event, next_record, and next_field
functions that walk that list. I also think we want a reset(), find_field(),
find_field_next() function to reset internal pointers,find a particular key,
and find the next instance of that key within the same event.
Are there any issues that need to be taken into account for Python
compatibility?
Debbie, did you have any comments?
-Steve