From mboxrd@z Thu Jan 1 00:00:00 1970 From: Miloslav Trmac Subject: Re: [PATCH] Fix acct quoting in audit_log_acct_message()) Date: Tue, 04 Mar 2008 20:08:47 +0100 Message-ID: <47CD9E3F.3000909@redhat.com> References: <47CCC6F0.1090005@redhat.com> <47CD65A3.8020204@redhat.com> <1204654248.12783.32.camel@vespa.frost.loc> <200803041356.19571.sgrubb@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <200803041356.19571.sgrubb@redhat.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: Steve Grubb Cc: linux-audit@redhat.com List-Id: linux-audit@redhat.com Steve Grubb napsal(a): > On Tuesday 04 March 2008 13:10:48 Tomas Mraz wrote: > This is basically the parsing rules: The header was defined a long time ago, > It parses in its own way, once we hit msg=, everything is name=value. We do > this by repeatedly calling strtok. These rules discard valuable information in currently defined audit records - so either the record format or the parsing rules need to change. That's unavoidable. > The biggest question to me is how you handle any transition from one format to > another. It will take time for patches to get upstream and then back > downstream. Meanwhile we could have audit logs being aggregated from a couple > different releases. They all need to parse correctly. How do we handle that? > I suspect the answer is to make the audit parser handle old and new formats > which adds a whole lot of code and makes it more complicated. Not really. If, to handle the transition, we need to parse the old records to the new semantic format (name-value pairs or something else), that does indeed add a whole lot of code. But we need that code even if we stay with the old format simply to process the information. Once we have the code to translate old records to a new, well-defined semantic format, modifying the code that generates the records to use a well-defined textual representation of the new semantic format requires only trivial (even if extensive) code modifications, and it is transparent to libauparse users. Applications that don't use libauparse can be best adapted by porting them to use libauparse; then we can even port the record-generating code incrementally over time, because the applications won't be able to tell the difference. Mirek