summaryrefslogtreecommitdiff
path: root/Documentation
diff options
context:
space:
mode:
authorEric Paris <eparis@redhat.com>2008-02-21 15:53:05 -0500
committerAl Viro <viro@zeniv.linux.org.uk>2008-03-01 07:16:06 -0500
commitb29ee87e9b441e72454efd1be56aa1a05ffb2f58 (patch)
tree03003a0f8cc126cd2ef3577f0db836e5d30ae22a /Documentation
parent422b03cf75e11dfdfb29b0f19709bac585335f86 (diff)
[RFC] AUDIT: do not panic when printk loses messages
On the latest kernels if one was to load about 15 rules, set the failure state to panic, and then run service auditd stop the kernel will panic. This is because auditd stops, then the script deletes all of the rules. These deletions are sent as audit messages out of the printk kernel interface which is already known to be lossy. These will overun the default kernel rate limiting (10 really fast messages) and will call audit_panic(). The same effect can happen if a slew of avc's come through while auditd is stopped. This can be fixed a number of ways but this patch fixes the problem by just not panicing if auditd is not running. We know printk is lossy and if the user chooses to set the failure mode to panic and tries to use printk we can't make any promises no matter how hard we try, so why try? At least in this way we continue to get lost message accounting and will eventually know that things went bad. The other change is to add a new call to audit_log_lost() if auditd disappears. We already pulled the skb off the queue and couldn't send it so that message is lost. At least this way we will account for the last message and panic if the machine is configured to panic. This code path should only be run if auditd dies for unforeseen reasons. If auditd closes correctly audit_pid will get set to 0 and we won't walk this code path. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Diffstat (limited to 'Documentation')
0 files changed, 0 insertions, 0 deletions