On Thursday, February 9, 2017 10:49:08 AM EST Richard Guy Briggs wrote:
On 2017-02-09 09:50, Steve Grubb wrote:
> On Thursday, February 9, 2017 9:06:57 AM EST Richard Guy Briggs wrote:
> > On 2017-01-13 10:48, Steve Grubb wrote:
> > > On Friday, January 13, 2017 3:26:29 AM EST Richard Guy Briggs wrote:
> > > > An AUDIT_SET message with the AUDIT_STATUS_LOST flag set by itself
> > > > will return a positive value repesenting the current audit_lost
> > > > value and reset the counter to zero. If AUDIT_STATUS_LOST is not
> > > > the only flag set, the reset command will be ignored. The value
sent
> > > > with the command is ignored. The return value will be the +ve lost
> > > > value at reset time.
> > > >
> > > > An AUDIT_CONFIG_CHANGE message will be queued to the listening audit
> > > > daemon. The message will be a standard CONFIG_CHANGE message with
> > > > the fields "lost=0" and "old=" with the latter
containing the value
> > > > of audit_lost at reset time.
> > >
> > > This passes testing and event looks good.
> >
> > Did you create a formal test for it or just test it manually?
>
> I tested this by building a kernel and testing it by hand.
Ok, this probably deserves a formal audit-testsuite case. What's the
exact format of the reset command?
auditctl --reset-lost
-Steve