Re: ausearch checkpoint capability

[Burn Alting <burn@swtf.dyndns.org>]

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