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