Re: get_field_str() and interpret_field() bug with multi-word fields

[John Dennis <jdennis@redhat.com>]

[-- Attachment #1.1: Type: text/plain, Size: 1558 bytes --]

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>


[-- Attachment #1.2: Type: text/html, Size: 2087 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]