Re: [PATCH] Add End of Event record

On Thu, 2007-09-27 at 09:16 -0400, Steve Grubb wrote: First let me say AUDIT_EOE is a good idea and I'm glad it's been added, but I'd like to make a couple of observations to put it context. How would a program determine AUDIT_EOE might be present in the audit "protocol" since there is no versioning of the "protocol" (using the term protocol loosely here, but in many respects streaming audit data is a protocol). Unless I'm mistaken the only way to determine if the protocol supports AUDIT_EOE is to watch for it and if it appears in the audit stream set a flag indicating event closure is determined by AUDIT_EOE as opposed to a duration interval. AUDIT_EOE does not make event assembly easier, one must still cache records until the event is complete. The advantage of AUDIT_EOE is explicit knowledge the event is complete as opposed to implicit knowledge the event is complete because a duration interval elapsed. The duration interval must be time based, an interval based on the number of intervening records will fail to close the event if the audit stream becomes quiescent. But since there is no guarantee AUDIT_EOE's will be in the protocol stream one must still be prepared to close events implicitly after a duration interval. Thus the single advantage of AUDIT_EOE's is to expedite the flushing of a complete event earlier than would be possible in the absence of the AUDIT_EOE record, otherwise the complexity of event assembly is unmodified. I believe the consequences are this: 1) A real time audit parsing library must still support both event closure mechanisms (note, parsing libraries are user space and independent of kernel versions and hosts). 2) The library when it opens an audit stream must start with it's closure mechanism set to "interval". 3) If AUDIT_EOE is seen the library sets it's closure mechanism to "EOE". Closed events will then be emitted earlier than previously. -- John Dennis <jdennis(a)redhat.com&gt;