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.

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.

Making 0 mean unlimited won't help embedded systems.

-Steve

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

On Wednesday, January 15, 2014 12:12:28 PM Richard Guy Briggs wrote: > > > 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. > > Eric and I had discussed that too, and I understand there is > considerable pushback to adding to kconfig, so that option would be > harder to get accepted. So how does making the backlog value of 0 be unlimited solve the problem?

-Steve

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