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

[John Dennis <jdennis@redhat.com>]

Linda Knippers wrote:
> Steve Grubb wrote:
>> In a binary representation, you would have a version number to 
>> describe what structure to cast the pointer to. If you have new log 
>> with old user space, it won't parse because it won't have the 
>> template to cast with.
>
> Is that any different from not being able to parse something the tools 
> don't know about?
It's useful to distinguish between two entirely different concepts which 
are at play here, but unfortunately get confused and intermingled, 
parsing and interpretation. A well designed protocol is always parsable 
by any version of the parser and any version of the input stream. This 
can be achieved because the protocol stream is well defined and any 
unknown protocol elements can be "stepped over". Once parsed any given 
protocol element is subject to interpretation, this is version specific. 
For example in the v2 protocol a "security identifier" (i.e. sid) might 
have been added, only a v2 tool could properly interpret the "sid" but a 
v1 parser could still parse the v2 stream (in fact a v1 parser should 
also be able to know the type of the unknown "sid", e.g. integer, 
string, etc.)

Extensible protocol design is a mature (and relatively simple) computer 
science discipline. The paradigm most likely to be familiar to people is 
ASN.1, but there are a host of other equally valid approaches, both 
binary and text based (I am not advocating for any given protocol design 
paradigm, but I do advocate we adopt one).

The reality is the audit stream is a protocol. The problem is the audit 
stream never had the principles of protocol design applied to it. We've 
tried to compensate for the lack of protocol rigorousness in the data 
stream by building a parser with special case exceptions and heuristics 
which is inherently unsustainable. If instead the audit data stream 
followed the rigours of a network protocol most of these issues would 
simply vanish.

-- 
John Dennis <jdennis@redhat.com>