From mboxrd@z Thu Jan 1 00:00:00 1970 From: John Dennis Subject: Re: get_field_str() and interpret_field() bug with multi-word fields Date: Wed, 13 Aug 2008 12:29:46 -0400 Message-ID: <48A30BFA.30600@redhat.com> References: <0E43BF2D7491F0468B56B1A5C493866B020DD0F1@SAT4MX07.RACKSPACE.CORP> <48A1EB72.6070607@redhat.com> <1218571902.3540.2.camel@localhost.localdomain> <200808121632.55341.sgrubb@redhat.com> <1218587598.3437.23.camel@klausk.br.ibm.com.br.ibm.com> <1218640141.3540.38.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1234273898==" Return-path: In-Reply-To: <1218640141.3540.38.camel@localhost.localdomain> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Eric Paris Cc: William Kelly , linux-audit@redhat.com, Bret Piatt List-Id: linux-audit@redhat.com This is a multi-part message in MIME format. --===============1234273898== Content-Type: multipart/alternative; boundary="------------000506030201040008050609" This is a multi-part message in MIME format. --------------000506030201040008050609 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Eric Paris wrote: > On Tue, 2008-08-12 at 21:33 -0300, Klaus Heinrich Kiwi wrote: > >> I think that if we take this discussion to extremes, we'd be talking >> about a 'self-descriptive meta language' so that upgrades to >> userspace/kernel are well covered (can you say "xml"?) >> > > HAHAHA, kernel output xml? dream on :) I'm willing to do wholesale > output changes, but something that heavy in kernel is impossible to > push. I can just see Al cussing up a storm as he read that. > Just to be clear no one is suggesting XML or anything heavy weight. Rather what is being suggested are trivial changes. For example string values are always enclosed in double quotes with interior characters properly escaped, or that non-decimal integer values include a radix prefix. I think one could simply summarize this as saying the lexical structure of value tokens match the lexical structure of the C programming language tokens which is pretty simple but unambiguous (plus there is a wealth of code to generate and parse these simple ubiquitous tokens). The implementation would be equally simple. Code which generates audit data calls a printf style varargs function which takes a format string and optional parameters. This single simple call is responsible for formatting a few basic data types which observes the token rules. To handle backward compatibility auparse could insulate users from the format changes by looking for either the old or new format, preferring the newer version. -- John Dennis --------------000506030201040008050609 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Eric Paris wrote: 
On Tue, 2008-08-12 at 21:33 -0300, Klaus Heinrich Kiwi wrote:
  
I think that if we take this discussion to extremes, we'd be talking
about a 'self-descriptive meta language' so that upgrades to
userspace/kernel are well covered (can you say "xml"?)
    

HAHAHA, kernel output xml?  dream on   :)   I'm willing to do wholesale
output changes, but something that heavy in kernel is impossible to
push.  I can just see Al cussing up a storm as he read that.
Just to be clear no one is suggesting XML or anything heavy weight. Rather what is being suggested are trivial changes. For example string values are always enclosed in double quotes with interior characters properly escaped, or that non-decimal integer values include a radix prefix. I think one could simply summarize this as saying the lexical structure of value tokens match the lexical structure of the C programming language tokens which is pretty simple but unambiguous (plus there is a wealth of code to generate and parse these simple ubiquitous tokens).

The implementation would be equally simple. Code which generates audit data calls a printf style varargs function which takes a format string and optional parameters. This single simple call is responsible for formatting a few basic data types which observes the token rules.

To handle backward compatibility auparse could insulate users from the format changes by looking for either the old or new format, preferring the newer version.
-- 
John Dennis <jdennis@redhat.com>
--------------000506030201040008050609-- --===============1234273898== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============1234273898==--