From mboxrd@z Thu Jan 1 00:00:00 1970 From: Richard Guy Briggs Subject: Re: [PATCH] audit: allow unlimited backlog queue Date: Wed, 15 Jan 2014 11:46:54 -0500 Message-ID: <20140115164654.GA23261@madcap2.tricolour.ca> References: <1389740356-18867-1-git-send-email-rgb@redhat.com> <20140114230432.GG23577@madcap2.tricolour.ca> <2007730.kZnoD1RoCs@x2> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <2007730.kZnoD1RoCs@x2> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Steve Grubb Cc: linux-audit@redhat.com List-Id: linux-audit@redhat.com 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 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