Audit change

Audit change

[Nowakowski Media]

[-- Attachment #1.1: Type: text/plain, Size: 172 bytes --]

If the audit messages would shift up 1 from the first_event you could track
the performance of the audit daemon. Having 2 messages typed with the same
number is confusing.

[-- Attachment #1.2: Type: text/html, Size: 194 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Audit change

[Steve Grubb]

On Sat, 19 Jan 2019 18:40:14 -0500
Nowakowski Media <johnnybanks604@gmail.com> wrote:
> If the audit messages would shift up 1 from the first_event you could
> track the performance of the audit daemon. Having 2 messages typed
> with the same number is confusing.

I am not sure I understand what you asking about. The audit system has
used the same numbering technique for at least 14 years. Maybe you are
referring to this:

audit(1520664214.224:39242)

In this time stamp we have 3 fields. To the left of the period is
seconds since 1970. Just to the right is millisecond within the seconds
since 1970. The last field after the colon is the serial number. The
serial number is used to group all records that are part of the same
event. There can be multiple events within the same millisecond so this
serial number also serves to differentiate other events withing the
same millisecond. At last, to make things more complicated, there is
nothing in the kernel that serializes the events. So, the stream that
comes out of the kernel and even written to disk can have 2 or more
events with interlaced records. The userspace utilities have to be
aware of this and reassemble the events correctly.

Hopefully I have given some background about how the time stamp is
used. Does this help? If not, could you explain your comment in a
little more detail?

Thanks,
-Steve