On Monday 22 May 2006 20:45, Leigh Purdie wrote:
> > * Be chronologically distributed in some cases (event lines
may be
> > spread over several seconds),
>
> Doubtful.
Excellent - thanks for that. I can reduce the threshold from 10 seconds to
closer to a second.
Yes. 2 seconds ought to get it if you only use time to the second. If you
handle milliseconds, maybe .5 second would do it. Generally the only delay
would be from the audit daemon doing its processing before handing you the
next event.
> > * Be out of sequence (numerically - two lines from event A,
might be
> > followed by 1 line from event B, then another line from event A,
> > followed by the rest of event B).
>
> I haven't seen this except when we introduced a bug in the kernel.
<snip>
Note the 228389, 228390, 228390, 228387, 228387, 228391, 228391 sequence.
Right, but they are not interlaced. You can protect against this just to be
safe.
> Yes, I'm glad to see more people use this feature. Please
note that there
> is an API version number that dictates the format of the records passed
> through the event dispatcher mechanism. Right now, the version is 0. It
> is the 1st 32 bit word sent in the dispatcher header. I should probably
> add a specification to my people page so that everyone knows the rules.
It would actually be very helpful, if the dispatcher could receive
normal, newline/null terminated strings, rather than having to
interpret C structures (with the record type expanded as ASCII text).
The audit daemon is just handing the same real-time information it received to
the dispatcher interface. I hate to make just this one change to the
protocol, though. (To make this change, I need to bump the protocol version
number. I hate to waste them.) If there were other changes that need to be
made, I'd feel better about doing the change now.
I also put an interface specification here:
http://people.redhat.com/sgrubb/audit/audit-rt-events.txt
If you see anything that need clarification, please let me know.
Yes. However, can the dispatcher guarantee that the paths in CWD and
PATH are fully resolved? (ie: we'll never see a
"/tmp/.././etc/./passwd" in PATH ?)
You could very well see that. I just tested what you wrote and it shows up
relative path and all. Also...please note that if the file name has a space
in it, you get a ascii hex representation of the file name.
-Steve