From: Steve Grubb <sgrubb@redhat.com>
To: Leigh Purdie <intersect@gmail.com>
Cc: linux-audit@redhat.com
Subject: Re: Dispatcher - single line output (perl)
Date: Tue, 23 May 2006 10:22:07 -0400 [thread overview]
Message-ID: <200605231022.07066.sgrubb@redhat.com> (raw)
In-Reply-To: <1ba978500605221745q3c5e3e99w50abe849c5a599fd@mail.gmail.com>
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
next prev parent reply other threads:[~2006-05-23 14:22 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-05-22 12:35 Dispatcher - single line output (perl) Leigh Purdie
2006-05-22 14:22 ` Steve Grubb
2006-05-23 0:45 ` Leigh Purdie
2006-05-23 14:22 ` Steve Grubb [this message]
2006-05-24 1:26 ` Leigh Purdie
2006-05-24 12:41 ` Steve Grubb
2006-05-25 0:22 ` Leigh Purdie
2006-05-25 12:30 ` Steve Grubb
2006-05-25 13:52 ` Steve Grubb
2006-08-08 1:32 ` Leigh Purdie
2006-05-24 15:14 ` Valdis.Kletnieks
2006-05-25 0:26 ` Leigh Purdie
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200605231022.07066.sgrubb@redhat.com \
--to=sgrubb@redhat.com \
--cc=intersect@gmail.com \
--cc=linux-audit@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox