<html><body> <tt>> 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. </tt> <tt>Alright, I'm not sure if I made my point clearly (or perhaps I am misundersanding yours), what is happening with our test cases is the following:</tt> <tt>system("/etc/rc.d/init.d/auditd start");</tt> <tt>...</tt> <tt>TEST(syscall(..))</tt> <tt>...</tt> <tt>system("/etc/rc.d/init.d/auditd stop");</tt> <tt>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).</tt> <tt>As it was explained to me, the way the stop works is when auditd is told to "stop", the daemon dies, and any audit messages still in the queue are "lost" in respect to the log file. 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.</tt> <tt> > It is assumed that when you send the stop...you really mean it. Everything > after that is discarded.</tt> <tt>Which makes sense, no issue there...</tt> <tt> > > 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.</tt> <tt>OK, good point. I remember it being mention during a meeting, but was there any further discussion about a "auditd stop" & "auditd shutdown" option? I know it was in regards to clearing the specified rules, but it seems it could be associated with this. Inserting a message into the queue might not be the best solution for the afore stated reasons, and while I don't have any ideas right now, doesn't mean there isn't an answer.</tt> <tt> > > 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.</tt> <tt>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. Of course, while auditd is down, there is 0 chance at logging anything, so it could just be a moot point.</tt> <tt>- Mike</tt></body></html>