Re: get_field_str() and interpret_field() bug with multi-word fields
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