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

[John Dennis <jdennis@redhat.com>]

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

Steve Grubb wrote:
> On Tuesday 12 August 2008 13:49:37 Jonathan Kelly wrote:
>   
>> When using the python auparse library to call AuParser.interpret_field()
>> on a multi-word field, only the first word in the field is returned.
>> Using get_field_str() instead of interpret_field() yields the same
>> output.  I have verified that this issue exists in the C library, as
>> well as the Python.  I suspect that this may be an issue for multi-word
>> fields in general, but have not noticed any other than 'op'.
>>     
>
> I am going to expose the encoder in libaudit in the next release so that 
> fields that have spaces can be escaped such that the parser can handle it. 
> Since the next release or two will be going into RHEL5, any other changes are 
> a non-starter. 
>   

This is another band-aid compounding the problem by entrenching the hack 
further into more code which will then have to be modified when a 
correct solution is finally put into place.

Providing an encoder entry point for code which generates audit 
key/value pairs does not fix the ambiguous parsing problem. During 
parsing one still has to know a priori which field names in which 
records are candidates for the hack, it is impossible to correctly parse 
otherwise. It also does not address the problem that decoding the hex 
value is only performed by "interpret", which is also the wrong 
location, it needs to be done during parsing and the field value needs 
to be returned with the string restored to it's correct value prior to 
transport encoding.

So many people have complained about this; I do not understand the 
resistance to fixing it. The argument it would break something which is 
broken to begin with does not seem like a reasonable justification to 
me. The sooner it's fixed the better IMHO.

-- 
John Dennis <jdennis@redhat.com>


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

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