Miloslav Trmač wrote:
A primary purpose of the audit system is to log with the greatest accuracy possible the actual data. If that data somehow contained a null, even in a context in which a null would have been prohibited, the audit system absolutely needs to be able to correctly record that aberrant event and it's actual data. If the audit system failed at that moment it's failing at the worst possible moment, the moment when you're looking for bad data.John Dennis píše v Čt 11. 09. 2008 v 13:30 -0400:Special processing with regards to the presence or absence of a null byte is one example of prohibited interpretation.This is UNIX, "string" means "NUL-terminated string" (in fact the presence of a NUL byte is the only way to reasonably detect binary data).
A UNIX-like operating system does not in and of itself mandate the default conventions of the C programming language. A great danger and the source of bugs is making assumptions concerning how to interpret octet sequences. By far and away the worst possible place to make a mistake handling an octet sequence is in the kernel. It would be wrong for the audit system to assume the memory block it was pointed to only ever contained null terminated ascii strings, especially when the memory block is terminated by virtue of an octet count.
You're far more likely to encounter a fixed-length field with an optional terminating NUL (like the old-style, 16-byte directory entries) than an ASCII-compatible string that intentionally contains a NUL byte.
-- John Dennis <jdennis redhat com>