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

[Steve Grubb <sgrubb@redhat.com>]

On Wednesday 13 August 2008 12:25:09 Klaus Heinrich Kiwi wrote:
> I like Mathew's idea of having a binary format though. Maybe it's
> possible to carry the legacy format for some time while we have a more
> robust (and extensible) binary format in parallel? And then having a
> binary format version tag within each record?

Yes, there would have to be a migration path. I think we talked about XDR as a 
possibility 4 years ago because its already inside the kernel. The kernel 
guys at the time wanted to re-use something already inside or something that 
was compact in its representation.

What I believe lead to text based was the general feeling that logs should be 
human readable with less, tail, or vi if need be.

A problem with binary representations will be what happens with aggregated 
big-endian and little-endian system logs?


> I know I know, at the time I have more questions than answers. I only
> wanted to express my feeling that there is indeed a problem with the
> current format.

There is a problem with any format. How would changing to binary help when we 
realize that we forgot auid in CONFIG_CHANGE? The only thing that might help 
is to stab a version number into each record because its size is going to 
change. This is going to lead to much more complex code in the parser.

The current technique is flexible in that the field is either there or not but 
it parses either way. For example, we recently added ses to syscall records. 
The auparse library can handle it being there or not. Now and in the future. 
The application that uses those logs may have to decide whether that's 
important or not. I don't think that is a judgment call for a library to 
make.

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.


> I know you and Steve tried before to talk with the SELinux guys trying
> to have a saner format for AVCs and stuff. Do you feel that's an
> impossible barrier to cross or maybe we try again and convince them that
> stricter formatting rules will bring more users for their audit data?

I don't know their recent thoughts on this. USER_AVC is seriously broken and 
unusable. I've been thinking about linking auparse to sending user space 
events to make sure that only parsable events are sent (it would go to syslog 
with an error so that its not lost forever). No app should consider sending 
an event as a performance impact, so this should be doable - but not in the 
1.7.x seres.  :)

-Steve