<meta http-equiv="Content-Type" content="text/html; charset=utf-8"><div dir="auto">Yes，I know those configurations，rate_limit just limit audit log speed，hitting a rate limit is a common scenario. For audit，should we do printk or not？</div><div dir="auto"><br></div><div dir="auto">Thanks for taking time to review it.</div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Paul Moore <paul@paul-moore.com>于2022年8月24日 周三03:27写道：<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">On Mon, Aug 22, 2022 at 10:33 PM Gaosheng Cui <ecronic@outlook.com> wrote:
<br>>
<br>> Thanks for your reply.
<br>>
<br>> This is a personal idea of mine，in the process of using audit，I find that if the audit rules are configured too much，or the server hard-disk performance is too poor，hitting a rate limit will be easy to occur，then some logs would be dropped directly.
<br>> I think we should print the record to the console，just likely the last thing we want to do，better play the role of audit，and improve kernel security.
<br>>
<br>> I hope that will be helpful，thanks.
<br>
<br>Yes, thank you for the additional information on your environment and
<br>use case.  As I'm sure you already know, the audit rate limit, backlog
<br>queue depth, and other related tunables can all be configured at boot
<br>or runtime to help ensure that the system remains responsive in the
<br>face of higher audit loads.
<br>
<br>-- 
<br>paul-moore.com
<br></blockquote></div></div>