On Tue, 2008-08-12 at 16:32 -0400, Steve Grubb wrote: > > And any code created needs to be backwards compatible. you could have new > user > space/new kernel, or new user space/old kernel, and new kernel/old user > space. You have no way of dictating which versions of anything people will > use.
But isn't this the exact situation we face now? I remember people asking in this list about audit for RHEL4, and in the end the problem was that they had their kernel upgraded so userspace and kernel were not in sync... I think that if we take this discussion to extremes, we'd be talking about a 'self-descriptive meta language' so that upgrades to userspace/kernel are well covered (can you say "xml"?) On the other hand, I do agree that the way it's currently implemented is prone to error when it comes to reporting/analyzing data. e.g., I remember fixing a 'mode' field in an audit object where it was being displayed as hex where we would expect an octal. In the future, when parsing this field, how would I know which radix a mode=003 field is? Fundamentally, was the record generated in patched kernel or not? If we take this change applied to every kernel and userspace change of the audit records, how can auparse possibly cover all cases? I also feel that stricter message format rules for userspace would help. Nowadays is difficult to 'reconstruct' the meaning of an audit record just by looking at their fields. Some fields don't even have a value, other use the same field twice in the same record. And for most people wanting to analyze audit data the fields=value pairs are the only reliable source. -Klaus -- Klaus Heinrich Kiwi <[EMAIL PROTECTED]> Linux Security Development, IBM Linux Technology Center -- Linux-audit mailing list [email protected] https://www.redhat.com/mailman/listinfo/linux-audit
