Re: [PATCH] audit: allow unlimited backlog queue

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).