Re: auditd stop suggestion
On Tuesday 14 June 2005 15:34, Michael C Thompson wrote:
what is happening with our test cases is the following:
system("/etc/rc.d/init.d/auditd start");
...
TEST(syscall(..))
...
system("/etc/rc.d/init.d/auditd stop");
Now, the outter portion of the code here (that is, before the start, and
after the stop) should not be affecting the actions taken between start and
stop (seems obviously correct, could be wrong). The issue we're
experiencing is that when the stop is called, the audit.log file has no
trace of what has transpired between the "start" & "stop" auditd
calls.
However, without putting sleeps (e.g. sleep(2); seems to be the most
effective) before we call "../auditd stop" then the records in file which
we are hoping to verify with are not there, unless we prolong the stop
(i.e. with a sleep).
Right you need to add a sleep. audit records do not show up instantaneously.
How long it takes could be subject to debate. I'd be more interested in
figuring that out.
As it was explained to me, the way the stop works is when auditd is
told to
"stop", the daemon dies,
Not really. It goes through a series of steps to stop processing and write the
shutdown record. It does not just die.
and any audit messages still in the queue are
"lost" in respect to the log file.
This is true. Stopping the audit daemon is an arbitrary act. You cannot tell
it stop after I get what I want. When you say stop...it has to stop.
If you could confirm that, or point me
to a place where that's documented and I'll read it for my self, it would
help me to understand the behaviour better.
Its in the auditd code. No docs.
OK, good point. I remember it being mention during a meeting, but was
there
any further discussion about a "auditd stop" & "auditd shutdown"
option?
No.
Right, the tests we are running are not a good indicator of the way
auditd's running status will be treated in a real environment, but there
must be some valid reasons for stopping auditd outside of a shutdown in a
real environment, which would still have this queue issue.
How would you know that what you want is already written to disk? If you have
a stream of events coming in non-stop and you have to stop the audit daemon,
you are going to have to cut off at some point. How can you pick any packet
as the last one? They are all equally important. So, the daemon may as well
stop at the instant its told to.
-Steve