Steve Grubb <sgrubb(a)redhat.com> writes:
I am ready to begin defining requirements for an audit event
extraction and parsing library.
One aspect of such a library is to define the structure of events as
seen by consumers of the information. 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.
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.
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. */
/* The value may be NULL. */
void (*entry)(const char *key, const char *value);
} *audit_event_callback_t;
int gimme(audit_event_callback_t a_callback/* other input */) {
/* ...*/ return 0;
}
With this kind of interface, if an audit event consumer passed the
pointer aec as its callback to the gimme function for data ausearch
would output as:
----
type=SYSCALL syscall=umount2
type=PATH name=/media/LEXAR_MEDIA
the following calls would be produced.
aec->entry("type", "SYSCALL");
aec->entry("syscall", "umount2");
aec->end_table();
aec->entry("type", "PATH");
aec->entry("name", "/media/LEXAR_MEDIA");
aec->end_table();
aec->end_event();
On another topic, I would like to see the library interface commit to
providing only US-ASCII strings. This way, issues of character sets
can be avoided.
John