From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve Grubb Subject: Re: Are the writing of an events records to audit.log atomic should a log rotation occur Date: Mon, 04 Feb 2013 14:32:18 -0500 Message-ID: <23054651.VinVpYuuhG@x2> References: <1359762689.3612.11.camel@swtf> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1359762689.3612.11.camel@swtf> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: linux-audit@redhat.com, burn@swtf.dyndns.org List-Id: linux-audit@redhat.com 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