Performance of libauparse
LC Bruzenak
lenny at magitekltd.com
Wed Oct 1 19:20:13 UTC 2008
On Wed, 2008-10-01 at 14:38 -0400, Paul Moore wrote:
> On Wednesday 01 October 2008 9:15:27 am Eric Paris wrote:
> > On Tue, 2008-09-30 at 15:18 -0400, John Dennis wrote:
> > > Eric likes to point out we can't change the
> > > kernel
> >
> > Close, but not quite. I say we can't change the kernel without
> > complete backwards compatibility. Show me the right solution and we
> > can get there, we just can't throw away what's already there.
>
> Not really aimed at anyone in particular, just throwing out a possible
> solution ...
>
> 1. By default kernel starts up and emits existing string format, legacy
> audit daemons function normally
> 2. If a new audit daemon starts it sends a message to the kernel
> indicating that it can handle the new format and the kernel starts
> emitting newly formatted records[1]
> 3. The new audit daemon records the audit records in whatever format it
> is configured to so: legacy string format, raw binary format, and/or
> some wacky format yet to be invented[2]
>
> [1] The new record format should probably a binary format which makes
> use of netlink attributes, this would avoid much of the string parsing
> and versioning problems we have seen previously. There is ample
> evidence of kernel subsystems using netlink in a similar fashion
> successfully.
>
> [2] If done carefully, we might be able to allow administrators to
> create their own on-disk string formats without the need to write an
> entire dispatcher plug-in.
>
This isn't a vote against (since I haven't fielded yet), but I could see
it could throw the user-space tools a curve (especially option [2])
regarding legacy data.
Might have to register the format spec inside the log file?
LCB.
--
LC (Lenny) Bruzenak
lenny at magitekltd.com
More information about the Linux-audit
mailing list