From mboxrd@z Thu Jan 1 00:00:00 1970 From: LC Bruzenak Subject: Re: Performance of libauparse Date: Wed, 01 Oct 2008 14:20:13 -0500 Message-ID: <1222888813.15037.111.camel@homeserver> References: <48E22AC8.8010906@redhat.com> <48E27B7E.3050000@redhat.com> <1222866927.28251.115.camel@localhost.localdomain> <200810011438.17154.paul.moore@hp.com> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Return-path: Received: from mx3.redhat.com (mx3.redhat.com [172.16.48.32]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m91JKQN1019535 for ; Wed, 1 Oct 2008 15:20:26 -0400 Received: from mail.magitekltd.com (rrcs-24-242-137-197.sw.biz.rr.com [24.242.137.197]) by mx3.redhat.com (8.13.8/8.13.8) with ESMTP id m91JKEpK014042 for ; Wed, 1 Oct 2008 15:20:14 -0400 Received: from [24.242.137.194] (helo=[192.168.30.40]) by mail.magitekltd.com with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1Kl7Ez-0007FQ-KP for linux-audit@redhat.com; Wed, 01 Oct 2008 14:20:05 -0500 In-Reply-To: <200810011438.17154.paul.moore@hp.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: linux-audit@redhat.com List-Id: linux-audit@redhat.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