From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve Grubb Subject: Re: EOE events in auparse output Date: Mon, 05 Dec 2016 10:27:47 -0500 Message-ID: <1583364.QtL6vz97jr@x2> References: <6ac1558f-fe8b-3e6a-decf-cdb31c180505@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <6ac1558f-fe8b-3e6a-decf-cdb31c180505@redhat.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Nikolai Kondrashov Cc: linux-audit@redhat.com List-Id: linux-audit@redhat.com On Monday, December 5, 2016 3:00:39 PM EST Nikolai Kondrashov wrote: > I was playing with auditd and aushape on Fedora 24 and found some strange > entries in my log. There was a separate *event* produced by auparse > containing a single EOE record. These events had the same serial number as > the directly preceding events, which were exclusively containing SYSCALL > records. > > Those EOE records didn't appear in the audit.log file. > > Is this a bug? Is this normal? The record is not created by auparse. The kernel sends this whenever there is a multipart event. This record is stripped before putting the event to disk to save disk space. We can get along with this because it can be deduced later and running reports from disk is not realtime. On the realtime interface it is passed along so that recognizing that an event is complete can occur immediately upon receipt. Realtime event processing kind of needs this guarantee. -Steve