On Monday, May 20, 2013 11:04:30 AM John Barnes wrote:Yes, these are -1, which is unset. This event is created by the kernel.
> I set up 4 simple audit rules using audictl:
>
> auditctl -w "/path/to/my/bin0" -p x
> auditctl -w "/path/to/my/bin1" -p x
>
> The rules were applied and show in auditctl -l. I tested them and
> they successfully log the execution of both binaries.
>
> However the rules were mysteriously flushed with only
> the following available in ausearch -m CONFIG_CHANGE:
>
> time->Sat May 18 00:03:19 2013
>
> type=CONFIG_CHANGE msg=audit(1368831799.081:466947): auid=4294967295
> ses=4294967295 op="remove rule" path="/path/to/my/bin0" key=(null) list=4
> res=1
>
> time->Sat May 18 00:03:19 2013
>
> type=CONFIG_CHANGE msg=audit(1368831799.081:466948): auid=4294967295
> ses=4294967295 op="remove rule" path="/path/to/my/bin1" key=(null) list=4
> res=1
>
> The uid doesn't match any known user so I presume these are initiated by
> the kernel.
I think if your file is deleted, then it removes the associated rule.
> The system wasn't under any pressure at the time (mem/load
> average fine), there was plenty of disk space available in all volumes, and
> the auditd was not restarted and the logs were not rotated.
>
> Is there anything that can cause the rules to be flushed in this way? It's
> a little concerning that they've just disappeared.
-Steve