Re: Performance of libauparse

[LC Bruzenak <lenny@magitekltd.com>]

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@magitekltd.com