On 16/06/09, Steve Grubb wrote:
On Thursday, June 09, 2016 07:59:43 PM Richard Guy Briggs wrote:
On 16/06/09, Steve Grubb wrote:
On Wednesday, June 08, 2016 10:05:01 PM Deepa Dinamani wrote:
struct timespec is not y2038 safe. Audit timestamps are recorded in string format into an audit buffer for a given context. These mark the entry timestamps for the syscalls. Use y2038 safe struct timespec64 to represent the times. The log strings can handle this transition as strings can hold upto 1024 characters.
Have you tested this with ausearch or any audit utilities? As an aside, a time stamp that is up to 1024 characters long is terribly wasteful considering how many events we get.
Steve,
I don't expect the size of the time stamp text to change since the format isn't being changed and I don't expect the date stamp text length to change until Y10K, but you never know what will happen in 8 millenia... (Who knows, maybe that damn Linux server in my basement will still be running then...)
Isn't the maximum message length MAX_AUDIT_MESSAGE_LENGTH (8970 octets)?
Bytes, yes. But I was thinking that if its going to get big we should consider switching from a base 10 representation to base 16. That would give us back a few bytes. We discuss this on the linux-audit list rather than the main list.
This seems like a false economy to me. If I understand correctly, it will be 285 years before we roll the next text digit. The next binary digit in the internal kernel format is in 22 years.
I know there have been discussions about changing to a binary format, which seems to have a lot more to offer than breaking the current format for a few bytes.
Is this not the linux-audit main list? Is there another one I am missing?
-Steve
- RGB
-- Richard Guy Briggs rgb@redhat.com Kernel Security Engineering, Base Operating Systems, Red Hat Remote, Ottawa, Canada Voice: +1.647.777.2635, Internal: (81) 32635