auditd stop suggestion

[Steve Grubb]

On Tuesday 14 June 2005 11:30, Michael C Thompson wrote:
> I was wondering, based on the amounts of sleeps we are needed to put into
> our test cases (and this might already have been said, if so, keep the
> flames to a low simmer) is there some way to change auditd stop to have it
> capture all of the messages up until the point where the stop was issued?

It does capture all the events up to the point the stop was issued. However, 
the stop and the messages travel in 2 different paths. One is a signal which 
entirely avoids the queue.

It is assumed that when you send the stop...you really mean it. Everything 
after that is discarded.

> Seems to me that while this change doesn't have to come now, it would be a
> nice addition in the future. Perhaps having the auditd stop insert a
> message into the queue (if thats possible?) 

We talked about this at length. What if the new event causes a kernel panic 
due to backlog overflow? Or what if they don't have failure set to panic, the 
audit daemon is waiting for a record that will never be sent. If a shutdown 
is occurring, you won't have the audit stop message.

> and have auditd die when it seems that message, as opposed to just dropping
> dead when the stop is made, causing a possible (and highly probable, happens
> all the time with our  tests if they don't have sleeps) loss of information.

You are in the unique position of expecting something in the logs. In the real 
world use, the machine is going down and you need to finish up asap or not 
audit stop message will get written.

-Steve