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

[John Dennis <jdennis@redhat.com>]

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

Eric Paris wrote:
> On Tue, 2008-08-12 at 15:58 -0400, John Dennis wrote:
>
>   
>> 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.
>>     
>
> Show me the code and I'll start trying to fix the kernel based on that
> code as best we can.  But before you start read over the article
>
> Can user-space bugs be kernel regressions?
> http://lwn.net/Articles/292143/
>
> As soon as you grasp that article send me the code and we'll work
> together to fix this problem!
>
>   

Perhaps you should grasp the concept this is not a user space bug but a 
flawed implementation. Anyone with the most basic understanding of 
parsing and protocols would never defend the current implementation (the 
fact it's in the kernel does not suspend the laws of computer science 
and justify it).

Let me give you a simple example, suppose this key/value pair was in an 
audit record:

foo=00

How does one know which of the possible values foo has:

1) it's the integer zero (but in what radix? does the leading zero imply 
octal or is it just an insignificant digit?)

2) it's the hexadecimal encoding of a single character string containing 
one null byte.

3) it's the 2 character string "00" consisting of two zero characters.

The fact is it's ambiguous, it could be any of the above. It's ambiguous 
because the audit stream is an improperly specified protocol.

-- 
John Dennis <jdennis@redhat.com>


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

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