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

John Dennis
2008-08-13T16:29:46Z

[-- 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 --]