Re: [PATCH] audit: allow unlimited backlog queue

On Wednesday, January 15, 2014 11:46:54 AM Richard Guy Briggs wrote: > 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? It would be explaining to the systemd people what problem we are having and asking for advice or changes to their sequence of what gets started when. > > 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). What about making it a compile time choice in the kernel config? I suggested making a compile time option, distributions can bump that up to 512, the default is enough and it can be tuned. Embedded can make the default whatever they want, too.

-Steve