ausearch checkpoint capability

ausearch checkpoint capability

[Burn Alting]

Steve,

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).

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.
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.

Steve,

I can provide a patch. Do you want it?

Rgds
Burn

Re: ausearch checkpoint capability

[Steve Grubb]

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

Re: ausearch checkpoint capability

[Burn Alting]

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

Re: ausearch checkpoint capability

[Steve Grubb]

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

Re: ausearch checkpoint capability

[Joe Wulf]

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

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

  +1

R,
-Joe



>________________________________
> From: Steve Grubb <sgrubb@redhat.com>
>To: burn@swtf.dyndns.org 
>Cc: linux-audit@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@redhat.com
>https://www.redhat.com/mailman/listinfo/linux-audit
>
>
>

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

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

Re: ausearch checkpoint capability

[Burn Alting]

[-- Attachment #1: Type: text/plain, Size: 5502 bytes --]

All,

Attached is a patch that modifies the --start option to take the string
'checkpoint' as an option. It will then extract the timestamp found
within the given checkpoint file and use that as the start time to emit
audit events for.

You will note that this patch also corrects a very minor error in the
ausearch(8) manual page where incorrect terminology was used in the -ts
or --start option description. It incorrectly duplicated elements of the
-te or --end option text.

Regards
Burn

On Mon, 2014-08-18 at 15:29 -0700, Joe Wulf wrote:
> This makes sense to me.  I am all for it.
> 
> 
>   +1
> 
> 
> R,
> -Joe
> 
> 
> 
>         
>         ______________________________________________________________
>         From: Steve Grubb <sgrubb@redhat.com>
>         To: burn@swtf.dyndns.org 
>         Cc: linux-audit@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@redhat.com
>         https://www.redhat.com/mailman/listinfo/linux-audit
>         
>         
>         
>         
> 


[-- Attachment #2: audit-2.3.7_checkpoint_errata.patch --]
[-- Type: text/x-patch, Size: 7647 bytes --]

diff -Npru audit-2.3.7/docs/ausearch.8 audit-2.3.7_checkpoint_errata/docs/ausearch.8
--- audit-2.3.7/docs/ausearch.8	2014-06-04 02:06:03.000000000 +1000
+++ audit-2.3.7_checkpoint_errata/docs/ausearch.8	2014-08-20 17:59:45.138353268 +1000
@@ -134,13 +134,29 @@ is assumed. Use 24 hour clock time rathe
 You may also use the word: \fBnow\fP, \fBrecent\fP, \fBtoday\fP, \fByesterday\fP, \fBthis\-week\fP, \fBweek\-ago\fP, \fBthis\-month\fP, \fBthis\-year\fP. \fBToday\fP means starting now. \fBRecent\fP is 10 minutes ago. \fBYesterday\fP is 1 second after midnight the previous day. \fBThis\-week\fP means starting 1 second after midnight on day 0 of the week determined by your locale (see \fBlocaltime\fP). \fBThis\-month\fP means 1 second after midnight on day 1 of the month. \fBThis\-year\fP means the 1 second after midnight on the first day of the first month.
 .TP
 .BR \-ts ,\  \-\-start \ [\fIstart-date\fP]\ [\fIstart-time\fP]
-Search for events with time stamps equal to or after the given end time. The format of end time depends on your locale. If the date is omitted, 
+Search for events with time stamps equal to or after the given start time. The format of start time depends on your locale. If the date is omitted, 
 .B today
 is assumed. If the time is omitted, 
 .B midnight
 is assumed. Use 24 hour clock time rather than AM or PM to specify time. An example date using the en_US.utf8 locale is 09/03/2009. An example of time is 18:00:00. The date format accepted is influenced by the LC_TIME environmental variable.
 
-You may also use the word: \fBnow\fP, \fBrecent\fP, \fBtoday\fP, \fByesterday\fP, \fBthis\-week\fP, \fBthis\-month\fP, \fBthis\-year\fP. \fBToday\fP means starting at 1 second after midnight. \fBRecent\fP is 10 minutes ago. \fBYesterday\fP is 1 second after midnight the previous day. \fBThis\-week\fP means starting 1 second after midnight on day 0 of the week determined by your locale (see \fBlocaltime\fP). \fBThis\-month\fP means 1 second after midnight on day 1 of the month. \fBThis\-year\fP means the 1 second after midnight on the first day of the first month.
+You may also use the word: \fBnow\fP, \fBrecent\fP, \fBtoday\fP, \fByesterday\fP, \fBthis\-week\fP, \fBthis\-month\fP, \fBthis\-year\fP, or \fBcheckpoint\fP. \fBToday\fP means starting at 1 second after midnight. \fBRecent\fP is 10 minutes ago. \fBYesterday\fP is 1 second after midnight the previous day. \fBThis\-week\fP means starting 1 second after midnight on day 0 of the week determined by your locale (see \fBlocaltime\fP). \fBThis\-month\fP means 1 second after midnight on day 1 of the month. \fBThis\-year\fP means the 1 second after midnight on the first day of the first month.
+.sp
+\fBcheckpoint\fP means \fIausearch\fP is to use the timestamp found within a valid checkpoint file as the start time to generate records from, ignoring the recorded inode, device, serial, node and event type also found within a checkpoint file. Essentailly, this is the recovery action should an invocation of \fIausearch\fP with a checkpoint option fail with an exit status of 10, 11 or 12. An appropriate script extract might look like
+.sp
+.in +5
+.nf
+.na
+ausearch --checkpoint /etc/audit/auditd_checkpoint.txt -i
+_au_status=$?
+if test ${_au_status} eq 10 -o ${_au_status} eq 11 -o ${_au_status} eq 12
+then
+  ausearch --checkpoint /etc/audit/auditd_checkpoint.txt --start checkpoint -i
+fi
+.ad
+.fi
+.in -5
+
 .TP
 .BR \-tm ,\  \-\-terminal \ \fIterminal\fP
 Search for an event matching the given \fIterminal\fP value. Some daemons such as cron and atd use the daemon name for the terminal.
diff -Npru audit-2.3.7/src/ausearch.c audit-2.3.7_checkpoint_errata/src/ausearch.c
--- audit-2.3.7/src/ausearch.c	2014-06-04 02:06:00.000000000 +1000
+++ audit-2.3.7_checkpoint_errata/src/ausearch.c	2014-08-20 17:21:17.594034276 +1000
@@ -58,6 +58,7 @@ static int process_file(char *filename);
 static int get_record(llist **);
 
 extern const char *checkpt_filename;	/* checkpoint file name */
+extern int checkpt_timeonly;		/* if non-zero, only use timestamp from within checkpoint file */
 static int have_chkpt_data = 0;		/* have checkpt need to compare wit */
 extern char *user_file;
 extern int force_logs;
@@ -244,8 +245,15 @@ static int process_logs(void)
 			 */
 			if (	(sbuf.st_dev == chkpt_input_dev) &&
 				(sbuf.st_ino == chkpt_input_ino) ) {
-				found_chkpt_file = num++;
-				break;
+				/*
+				 * If we are ignoing all but time, then we don't stop checking more
+				 * files and just let this loop go to completion and hence
+				 * we will find the 'oldest' file.
+				 */
+				if (!checkpt_timeonly) {
+					found_chkpt_file = num++;
+					break;
+				}
 			}
 		}
 
@@ -253,8 +261,11 @@ static int process_logs(void)
 		snprintf(filename, len, "%s.%d", config.log_file, num);
 	} while (1);
 
-	/* If a checkpoint is loaded but can't find it's file, error */
-	if (checkpt_filename && have_chkpt_data && found_chkpt_file == -1) {
+	/* If a checkpoint is loaded but can't find it's file, and
+ 	 * we are not only just checking the timestamp from the checkpoint file,
+ 	 * we need to error */
+	if (checkpt_filename && have_chkpt_data && found_chkpt_file == -1
+	&& !checkpt_timeonly) {
 		free(filename);
 		free_config(&config);
 		return 10;
@@ -342,6 +353,26 @@ static int chkpt_output_decision(event *
 		return 1;	/* can output on this event */
 	}
 
+	/*
+	 * If we are ignoring all but event time from within the checkpoint
+	 * file, then we output if the current event's time is greater than
+	 * or equal to the checkpoint time.
+	 */
+	if (checkpt_timeonly) {
+		if (
+			(chkpt_input_levent.sec < e->sec)
+		||
+			(
+				(chkpt_input_levent.sec == e->sec)
+			&&
+				(chkpt_input_levent.milli <= e->milli)
+			)
+		) {
+			can_output = 1;
+			return 1;   /* can output on this event */
+		}
+	}
+
 	if ( chkpt_input_levent.sec == e->sec &&
 		chkpt_input_levent.milli == e->milli &&
 		chkpt_input_levent.serial == e->serial &&
diff -Npru audit-2.3.7/src/ausearch-options.c audit-2.3.7_checkpoint_errata/src/ausearch-options.c
--- audit-2.3.7/src/ausearch-options.c	2014-06-04 02:06:00.000000000 +1000
+++ audit-2.3.7_checkpoint_errata/src/ausearch-options.c	2014-08-20 17:22:30.777824134 +1000
@@ -56,6 +56,7 @@ int event_session_id = -2;
 int event_exit = 0, event_exit_is_set = 0;
 int line_buffered = 0;
 int event_debug = 0;
+int checkpt_timeonly = 0;
 const char *event_key = NULL;
 const char *event_filename = NULL;
 const char *event_exe = NULL;
@@ -209,7 +210,7 @@ static void usage(void)
 	"\t-su,--subject <SE Linux context> search based on context of the Subject\n"
 	"\t-sv,--success <Success Value>\tsearch based on syscall or event\n\t\t\t\t\tsuccess value\n"
 	"\t-te,--end [end date] [end time]\tending date & time for search\n"
-	"\t-ts,--start [start date] [start time]\tstarting data & time for search\n"
+	"\t-ts,--start [start date] [start time]|['checkpoint']\tstarting data & time for search\n"
 	"\t-tm,--terminal <TerMinal>\tsearch based on terminal\n"
 	"\t-ua,--uid-all <all User id>\tsearch based on All user id's\n"
 	"\t-ue,--uid-effective <effective User id>  search based on Effective\n\t\t\t\t\tuser id\n"
@@ -873,7 +874,10 @@ int check_params(int count, char *vars[]
 							"00:00:00") != 0)
 							retval = -1;
 					}
-					else if ( strchr(optarg, ':') == NULL) {
+					else if ( strcmp(optarg, "checkpoint") == 0) {
+						/* Only use the timestamp from within the checkpoint file */
+						checkpt_timeonly++;
+					} else if ( strchr(optarg, ':') == NULL) {
 						/* Only have date */
 						if (ausearch_time_start(optarg,
 							"00:00:00") != 0)

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

Re: ausearch checkpoint capability

[Steve Grubb]

On Wednesday, August 20, 2014 06:18:35 PM Burn Alting wrote:
> Attached is a patch that modifies the --start option to take the string
> 'checkpoint' as an option. It will then extract the timestamp found
> within the given checkpoint file and use that as the start time to emit
> audit events for.

Thanks for the patch! Applied as commit 997.

-Steve