From mboxrd@z Thu Jan 1 00:00:00 1970 From: Burn Alting Subject: Re: ausearch checkpoint capability Date: Tue, 19 Aug 2014 07:49:50 +1000 Message-ID: <1408398590.845.3.camel@swtf.swtf.dyndns.org> References: <1408145116.1503.53.camel@swtf.swtf.dyndns.org> <26086601.oGHCGWl4C5@x2> Reply-To: burn@swtf.dyndns.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <26086601.oGHCGWl4C5@x2> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Steve Grubb Cc: linux-audit@redhat.com List-Id: linux-audit@redhat.com Steve, Just to confirm: the patch would be modify the --start command line processing to accept a string argument of 'checkpoint-time' AND if a checkpoint file has also been provided via the --checkpoint arg AND there is a timestamp within the specified file, we use the timestamp stored within the file? Rgds On Mon, 2014-08-18 at 14:13 -0400, Steve Grubb wrote: > Hello, > > On Saturday, August 16, 2014 09:25:16 AM Burn Alting wrote: > > One of the issues with ausearch's checkpoint code is how to recover from > > failures. A classic failure is to perform a checkpoint on a busy system > > and then delay too long before running the next invocation of ausearch > > and as a result of the delay, the checkpointed event cannot be found in > > the files in /var/log/audit. There are other failures, such as re-use of > > inodes etc. > > > > For those of you who haven't noted the ausearch --checkpoint change, it > > basically records the details of the last complete audit event it > > processed or printed in a checkpoint file. It records not only the event > > time, but also the event node, serial, type and the file device and > > inode. Thus, when you next invoke ausearch with this option, the next > > event to process is the next complete event since the one recorded. > > > > Should an error occur when attempting to find the next complete event to > > process, ausearch will exit. At this point, I believe the best recovery > > action is to extract only the event time from the checkpoint file and > > ask for all complete events after that time (i.e. as opposed to the > > usual action of comparing time, event id, type, log file details etc). > > Would anyone be opposed to making that the default behavior? > > > > There are at last two solutions: > > a. We can patch ausearch to take a --checkpoint-time-only flag which > > means ausearch will look for all events since the time in the checkpoint > > file. This provides the best granularity in time as it goes down to > > msecs. > > I am worried about the proliferation of command line switches. I'd rather make > a new --start target. e.g. --start checkpoint-time. > > > b. We extract the timestamp from the checkpoint file, convert it to a > > date and time and use ausearch's --start option to find all events since > > the time in the checkpoint file. > > > > The first provides greater granularity in time as it goes to msecs. > > If one is the timestamp of the file, that might be misleading. I don't know if > touching a file is an auditable event. No time to investigate right now either. > I'd rather see the time taken from within the file. > > > I can provide a patch. Do you want it? > > Sure, if its based on a --start target. > > -Steve