Eric Paris wrote:
On Tue, 2008-01-29 at 17:56 -0500, John Dennis wrote:
I'm certainly not going to argue this isn't problomatic. I believe that case #1 should go away. Maybe when I get back from Chile I'll get a chance to look at that. Some fields just aren't ever strings, so I don't see a need to waste time/space writing " around something I know is always an int. But if the field can be a string it should ALWAYS be either case 2 or 3.
I'm cool with not using quotes around everything, I very much see the appeal in that. But if you do that then *all* strings have to be quoted *and* you can't continue to use the current unquoted hexadecimal string encoding (case 3), it's ambiguous, you can't determine if its a string because the quotes would be missing. That means case 3 also must be eliminated. All strings have to be enclosed in quotes and what appears inside the quotes has to support encoding arbitrary bytes. FWIW backslash quoting meets this requirement, as does many other encodings in popular use.
It "shouldn't" depend on the kernel version, but I'm sure it does. I'm going to work on eliminating case 1, which makes a lot of this mute.
Eliminating both case 1 and case 3 would be necessary to make it moot. It would be a superb step forward and greatly appreciated.
What approach would you like when I try to audit binary data? You want me to start adding \x before every byte? Forget it, waste of space.
Encoding binary data is solved problem. Some encodings are more efficient than others, pick a standard encoding which satisfies your requirements. The only key is that when the input stream shifts into and out of encoded format it must be determinable only from the input stream. It cannot rely on private version specific knowledge that certain fields have this encoding.
I don't want to waste time/effort having to write res="1" when I can just say res=1. I know you are complaining that you have to look at message type, field name, and kernel version. My opinion, you should just have to look at field name.
I shouldn't have to look at the field name, this violates basic parsing rules and is tied to specific kernel versions, see first comment, there is an easy solution.
I've got no problems eliminating all of the %s in the code and making everything go through audit_log_string()
That would be a big step forward and would solve many of the problems, thanks. Just be aware audit_log_string has to use a different encoding other than bare hexadecimal.
My take, if the field name is something that can be a string you either get field="string" or you get field=737472696e67. Either way its easy to recognize. Quotes means string, no quotes means hex.
How does the parser know the field can be a string? See above. -- John Dennis <[EMAIL PROTECTED]> -- Linux-audit mailing list Linux-audit@redhat.com https://www.redhat.com/mailman/listinfo/linux-audit
