BUG: inconsistent audit rule processing when adding/removing rules

[weiyuchen]

I'd like to discribe the problem I encounter. If I start a bash(ex: pid 1396) before auditd (ex: pid 1427) , then I clear the audit rules with auditctl -D and add one single rule like -w /tmp/test -p wa -k mmm, after that I use the bash (pid 1396) to operate the file /tmp/test, (ex: echo xxx > /tmp/test), I can't get any audit log about this event. but if I start a new bash (ex: pid 1444) and execute the same command (ex: echo dddd > /tmp/test), I can get the normal audit log. I've analysis the logic of auditd, it seems that this kind of situation can't be logged, but in some emmbeded and other situations, some bash processes started earlier than auditd, which results in some commands (ex: echo xxx > xxx) audit logs are missing.

[pcmoore]

... it seems that this kind of situation can't be logged, but in some emmbeded and other situations, some bash processes started earlier than auditd, which results in some commands (ex: echo xxx > xxx) audit logs are missing.

As you've realized, there is a performance optimization where tasks started with auditing disabled do not regain auditing functionality once auditing is re-enabled. If your goal is to always have auditing enabled you should consider adding "audit=1" to the kernel command line.

Please let us know how this works for you.

[weiyuchen]

I've test on my environment, it works well~ thx

[pcmoore]

Glad you got it working, closing this issue.