Steve,
Please find attached a patch against 2.3.6 that, when checkpointing,
notices if we identify an audit.log file to use (ie the dev and inode
match) but we find a complete event whose time is > 2 seconds past the
checkpoint time. This should not happen, as the checkpoint event should
be found BEFORE any other complete event for the checkpoint event was
the last displayed complete event in the file. When this occurs, a
message is printed to stderr and ausearch will terminate with an exit
code of 12.
This typically occurs if there is a lot of processing or a long time
occurs between two invocations of ausearch --checkpoint. Basically, an
inode is reused in one of the new audit.log files.
Rgds
On Mon, 2014-04-14 at 20:11 -0400, Steve Grubb wrote:
On Sunday, April 13, 2014 11:51:45 AM Burn Alting wrote:
> A patch is attached that addresses this.
>
> Essentially the modification
> - notices if we identify an audit.log file to use but we do not find the
> recorded audit event in that log file and so report an error (to stderr)
> and return a new exit code (12)
> - allows checkpointing to only use the recorded time from the checkpoint
> file for comparisons.
I'd like to look at these two pieces separately. Let's have 1 bug/feature per
patch. This way if something looks good, it can be applied immediately.
Whereas if something needs more discussion, it would block application of the
part that is good.
> You will note that the patch also contains changes to swig/audit.py.
> Although this file is automatically generated, it is part of the 2.3.6
> release ... should it be?
I suppose it should be. What is in the release is decided by
automake/autoconf. If there are any mistakes in the Makefile.am file, I would
take a patch.
> I also note that a lot of Makefile.in's are also part of the release. Again,
> should these automatically generated files be part of the release?
The audit package release is done by a script that pretty much does the
following (its way more complicated than this, but this is the essential
pieces):
mkdir audit
cd audit
svn co
http://svn.fedorahosted.org/svn/audit/trunk .
./autogen.sh
./configure
make -j 8 distcheck
If it finishes saying it created the tar ball, I send it to rawhide to make
sure it builds on a current OS. If that is also successful, then I push it to
my people page and then commit a branch in svn. I also run the development
audit package on all my systems during the whole development cycle to make
sure bugs are fixed, nothing new shows up, and its builds under normal
conditions.
So, anything that is there, is because autotools think it should be there
unless I made a mistake in a Makefile.am. :-) Patches are welcome.
Thanks,
-Steve