[PATCH] audit: allow unlimited backlog queue

[Richard Guy Briggs]

On 14/01/15, Steve Grubb wrote:
> On Tuesday, January 14, 2014 06:04:32 PM Richard Guy Briggs wrote:
> > On 14/01/14, Richard Guy Briggs wrote:
> > > Since audit can already be disabled by "audit=0" on the kernel boot line,
> > > or by the command "auditctl -e 0", it would be more useful to have the
> > > audit_backlog_limit set to zero mean effectively unlimited (limited only
> > > by system resources).
> > >
> > > These are userspace source code documentation changes in what's going in
> > > upstream.  See:
> > >       audit: allow unlimited backlog queue
> > > git://toccata2.tricolour.ca/linux-2.6-rgb.git
> > > https://lkml.org/lkml/2013/10/22/356
> > > https://www.redhat.com/archives/linux-audit/2013-October/msg00029.html
> > 
> > And this is a related BZ:
> > https://bugzilla.redhat.com/show_bug.cgi?id=999756
> 
> This patch doesn't make sense in that context either. The problem is systemd 
> floods the audit system before auditd comes up. This begs the question of 
> whether auditd is being started early enough.

Or that the queue isn't long enough.

Do you have any specific ideas on getting auditd started earlier?

> One solution from that bz is to make a boot time config option. Problem is, 
> everyone that really cares about audit will have to set that. So that means 
> the default should be bumped up. However, the bz mentions that embedded 
> systems don't like that. So, why not make a compile time config option that 
> keeps the current default (64) and server/desktop distributions can make that 
> 512? You can even provide a boot time config so that people with really busy 
> systems can make it bigger if they choose.

There is a boot config option that has just been added to do that too:
	audit: add kernel set-up parameter to override default backlog limit

It will be upstream in 3.13.

Eric and I discussed bumping up the default.  I would have liked to have
seen somewhere between 320 and 512, but that default would make the
embedded folks unhappy and I don't really want to get into the more
complex idea of having it guess what type of system it is trying to
configure to give a smaller number for embedded systems (which aren't
all small) and bigger ones to servers (which aren't all big).

> Making 0 mean unlimited won't help embedded systems.

This is not trying to solve that problem.

> -Steve

- RGB

--
Richard Guy Briggs <rbriggs at redhat.com>
Senior Software Engineer, Kernel Security, AMER ENG Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545