From: Steve Grubb <sgrubb@redhat.com>
To: Richard Guy Briggs <rgb@redhat.com>
Cc: Arnd Bergmann <arnd@arndb.de>,
y2038@lists.linaro.org, linux-kernel@vger.kernel.org,
linux-audit@redhat.com, Al Viro <viro@zeniv.linux.org.uk>,
linux-fsdevel@vger.kernel.org,
Thomas Gleixner <tglx@linutronix.de>,
Linus Torvalds <torvalds@linux-foundation.org>,
Deepa Dinamani <deepa.kernel@gmail.com>
Subject: Re: [PATCH 17/21] audit: Use timespec64 to represent audit timestamps
Date: Thu, 09 Jun 2016 20:19:53 -0400 [thread overview]
Message-ID: <1850599.zs4hA4SSlr@x2> (raw)
In-Reply-To: <20160609235943.GL18488@madcap2.tricolour.ca>
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.
-Steve
_______________________________________________
Y2038 mailing list
Y2038@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/y2038
next prev parent reply other threads:[~2016-06-10 0:19 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1465448705-25055-1-git-send-email-deepa.kernel@gmail.com>
2016-06-09 5:05 ` [PATCH 17/21] audit: Use timespec64 to represent audit timestamps Deepa Dinamani
2016-06-09 14:31 ` Steve Grubb
2016-06-09 23:59 ` Richard Guy Briggs
2016-06-10 0:19 ` Steve Grubb [this message]
2016-06-10 1:44 ` Richard Guy Briggs
2016-06-15 21:23 ` Paul Moore
2016-06-10 0:45 ` Deepa Dinamani
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1850599.zs4hA4SSlr@x2 \
--to=sgrubb@redhat.com \
--cc=arnd@arndb.de \
--cc=deepa.kernel@gmail.com \
--cc=linux-audit@redhat.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rgb@redhat.com \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=viro@zeniv.linux.org.uk \
--cc=y2038@lists.linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox