Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1418985

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

From Richard Guy Briggs <rgb@redhat.com>
Newsgroups linux.kernel
Subject Re: [PATCH 17/21] audit: Use timespec64 to represent audit timestamps
Date 2016-06-10 03:50 +0200
Message-ID <rIjK9-6lV-3@gated-at.bofh.it> (permalink)
References <rI0o9-1PH-9@gated-at.bofh.it> <rI9hM-7C2-25@gated-at.bofh.it> <rIi1I-5bB-7@gated-at.bofh.it> <rIiuJ-5BG-13@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


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

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

[PATCH 17/21] audit: Use timespec64 to represent audit timestamps Deepa Dinamani <deepa.kernel@gmail.com> - 2016-06-09 07:10 +0200
  Re: [PATCH 17/21] audit: Use timespec64 to represent audit timestamps Steve Grubb <sgrubb@redhat.com> - 2016-06-09 16:40 +0200
    Re: [PATCH 17/21] audit: Use timespec64 to represent audit timestamps Richard Guy Briggs <rgb@redhat.com> - 2016-06-10 02:00 +0200
      Re: [PATCH 17/21] audit: Use timespec64 to represent audit timestamps Steve Grubb <sgrubb@redhat.com> - 2016-06-10 02:30 +0200
        Re: [PATCH 17/21] audit: Use timespec64 to represent audit timestamps Richard Guy Briggs <rgb@redhat.com> - 2016-06-10 03:50 +0200
    Re: [PATCH 17/21] audit: Use timespec64 to represent audit timestamps Deepa Dinamani <deepa.kernel@gmail.com> - 2016-06-10 02:50 +0200

csiph-web