[PATCH 2/2] audit: don't reset working wait time accidentally with auditd
Paul Moore
pmoore at redhat.com
Mon Feb 2 21:16:08 UTC 2015
On Friday, January 30, 2015 04:10:44 PM Richard Guy Briggs wrote:
> On 15/01/29, Paul Moore wrote:
> > On Tuesday, January 27, 2015 07:34:02 PM Richard Guy Briggs wrote:
> > > During a queue overflow condition while we are waiting for auditd to
> > > drain
> > > the queue to make room for regular messages, we don't want a successful
> > > auditd that has bypassed the queue check to reset the backlog wait time.
> > >
> > > Signed-off-by: Richard Guy Briggs <rgb at redhat.com>
> > > ---
> > >
> > > kernel/audit.c | 3 ++-
> > > 1 files changed, 2 insertions(+), 1 deletions(-)
> >
> > I'm still wondering why we ever change audit_backlog_wait_time, it is only
> > so we don't end up calling wait_for_auditd() multiple times while we are
> > waiting for the queue to drain?
>
> Not exactly. Up to the timeout, all subsequent callers will wait for
> auditd as well. It is so that if wait_for_auditd() does time out, we
> don't make new callers after that timeout wait, but return an error
> immediately. If/when auditd does manage to succeed and recover after
> that wait time, it will reset the wait time and resume normal operation.
Okay, thanks for the clarification on both patches. If I have one nit, it
would be that you could have merged both patches into a single patch; just
something to remember for future submissions.
Like the tree pruning thread patch, I'm going to queue this up for after this
upcoming merge window.
> > As a general comment, not directed at anyone in particular, the audit
> > backlog/queue handling looks a little odd ...
>
> Indeed...
I suspect we'll need to look closer at this code in the future, or rather I'll
*want* to look closer at this in the future but for right now I think we've
got enough to deal with.
--
paul moore
security @ redhat
More information about the Linux-audit
mailing list