Re: Audit Parsing Library Requirements

Klaus Weidner <klaus(a)atsec.com&gt; writes: I agree. I was thinking about why I proposed a callback-based interface, and Steve countered with a iterator based-interface. I don't think this difference is simply a matter of style, but rather a matter of expected usage. I would like a library interface that allows me to reuse existing functionality in ausearch, not just process raw records. Thus, I imagined at least two functions being part of the library. int from_stream(audit_event_callback_t aec, FILE *source); int ausearch(audit_event_callback_t aec /* ausearch options */); where typedef struct audit_event_callback { void (*end_event)(void); /* Note the end of an event. */ void (*end_table)(void); /* Note the end of a table in an event. */ /* Note one entry in a table in an event--a key-value pair. */ void (*entry)(const char *key, const char *value); } *audit_event_callback_t; The arguments to the ausearch function would mirror the information derived from the command-line arguments of the ausearch program. In fact, in this design, the ausearch program would simply convert its command-line arguments into C data types, create a callback that produces at textual representation of the search results, and then return the results of calling the ausearch library function with these parameters. I should explain my immediate interest is audit output. I'm working on an SELinux policy generation tool called Polgen that uses system call traces as one of its sources of information. Polgen currently gathers this information using a modified version of strace. I'm looking for output that mimics strace, so I assume I want system call records that have been interpreted, as is done by ausearch using the -i option. I'd like to easily use the record interpretation facility already built into ausearch, along with its other fine features. John