ausearch checkpoint capability

[Joe Wulf]

This makes sense to me.  I am all for it.

  +1

R,
-Joe



>________________________________
> From: Steve Grubb <sgrubb at redhat.com>
>To: burn at swtf.dyndns.org 
>Cc: linux-audit at redhat.com 
>Sent: Monday, August 18, 2014 5:59 PM
>Subject: Re: ausearch checkpoint capability
> 
>
>Hello,
>
>On Tuesday, August 19, 2014 07:49:50 AM Burn Alting wrote:
>> Just to confirm:
>> 
>> the patch would 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?
>
>Yes. I am close to doing a new release of the audit package. I am kind of 
>aiming towards the end of this week. If its ready by then, I'll include it in 
>the new release. If not, maybe next release.
>
>Also, if anyone else has bugs to report, patches to send, etc. now would be a 
>good time if they needed it to go out soonish.
>
>Thanks,
>
>
>
>
>-Steve
>
>
>> 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
>
>--
>Linux-audit mailing list
>Linux-audit at redhat.com
>https://www.redhat.com/mailman/listinfo/linux-audit
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/linux-audit/attachments/20140818/3eed0198/attachment.htm>