Dispatcher - single line output (perl)

[Steve Grubb]

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