Dispatcher - single line output (perl)

[Leigh Purdie]

Thanks for that Steve,

> 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.

Actually, they are. Hang on, and I'll give you a bigger example (event numbers):
$ cat audit.log | awk '{print $2}' | cut -d: -f2 | sed 's/)//' | grep
"2283[89][0-9]"
...
228386
228386
228386
228387
228388
228388
228388
228388
228389
228389
228389
228390
228390
228390
228387
228387
228391
228391
228391

Note the 228387 four from the top, and also after the 228390's.

Is this something that should be considered a bug? If so (and it's
likely to be fixed in RHEL4 in the near future), then I'll be able to
greatly simplify the dispatcher code. :)

> 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.

No problems. I'm in no hurry for it - I can definitely work around
this issue for our Snare-related requirements. :)

However, it's probably something that others would appreciate.
The protocol may not need to change explicitly, two separate paths in
auditd may be viable - ie:
dispatcher = /path/to/something-that-receives-a-raw-feed   or
asciidispatcher = /path/to/something-that-receives-nullterminated-ascii-to-stdin

.. if 'asciidispatcher' is active, auditd does a little extra work to
push the line out in a 'nicer' format.

> > 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.

No problems. The internal path resolver will cope with this (and the
CWD/PATH amalgamation).

> Also...please note that if the file name has a space
> in it, you get a ascii hex representation of the file name.

No worries - easy to cope with. Thanks for the hint.

Just spaces? How about inverted-commas, embedded newlines (or
Carriage-Returns), or other non-displaying characters that may be
valid on linux (or other) filesystems?

Also, anyone have any thoughts on how to translate "eventid 11" to a
more human-readable "execve" in perl without writing my own C Header
translator?

Regards,

Leigh.