Are the writing of an events records to audit.log atomic should a log rotation occur

[Steve Grubb]

On Saturday, February 02, 2013 10:51:29 AM Burn Alting wrote:
> All,
> 
> When rotating log files due a USR1 signal being sent, or for any other
> reason, does auditd finish writing all the
> records that belong to the current event being written before starting
> the new log file?

When it catches SIGUSR1, it sets a flag that is read by the event loop. So, 
this serializes it with other events. It does write the record out before 
rotating.

> That is, will I find records belonging to a single event in two log
> files?

That is a different question and a different answer. Events can be composed of 
multiple records. It is possible for a record to be emitted and at that time a 
check of the disk space used or file size may cause a rotation or some other 
action.

> If this is the case, would there be problems if auditd was changed to
> wait and 'flush' all an event's records before
> rotating? 

Auditd just writes to disk. It does not try to determine if anything is 
pending because its in a race to dequeue as fast as possible before buffers fill 
up. Any re-assembly of records into an event is done by aureport and ausearch.

> One assumes auditd-event.c would need to be modified to be
> more event aware. Perhaps make use of AUDIT_EOE or
> other means of identifying the end of an event or a single event.

It might be helpful to describe the problem this is solving.

Thanks,
-Steve