Re: [PATCH 17/21] audit: Use timespec64 to represent audit timestamps

On 16/06/09, Steve Grubb wrote:

On Thursday, June 09, 2016 07:59:43 PM Richard Guy Briggs wrote:

quoted

On 16/06/09, Steve Grubb wrote:

quoted

On Wednesday, June 08, 2016 10:05:01 PM Deepa Dinamani wrote:

quoted

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 [off-list ref]
Kernel Security Engineering, Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635