1. In audit rules 2.8.5 (front portion of the rules):
## Unsuccessful file access (any other opens) This has to go last.
-a always,exit -F arch=b32 -S open,creat,truncate,ftruncate,openat,open_by_handle_at -F exit=-EACCES
-a always,exit -F arch=b64 -S open,creat,truncate,ftruncate,openat,open_by_handle_at -F exit=-EACCES
-a always,exit -F arch=b32 -S open,creat,truncate,ftruncate,openat,open_by_handle_at -F exit=-EPERM
-a always,exit -F arch=b64 -S open,creat,truncate,ftruncate,openat,open_by_handle_at  -F exit=-EPERM
Whereas in audit rules 3.0, the same portion of the same rules looks like:
-a always,exit -F arch=b32 -S open,creat,truncate,ftruncate,openat,open_by_handle_at -F exit=-EACCES
-a always,exit -F arch=b32 -S open,creat,truncate,ftruncate,openat,open_by_handle_at -F exit=-EPERM
-a always,exit -F arch=b64 -S open,truncate,ftruncate,creat,openat,open_by_handle_at -F exit=-EACCES
-a always,exit -F arch=b64 -S open,truncate,ftruncate,creat,openat,open_by_handle_at  -F exit=-EPERM

The ordering of the syscalls differs between the two, as well as the sequential order of the rules themselves. I better understand that the first audit-rule matched 'wins'.
-  Please help me understand the reason for the change in sequence, but also for the change in the order of the syscalls (i.e. between 2.8.5 and 3.0).


2.  I notice there are many rules across the entire set (both 2.8.5 and 3.0) that define their key with "-F key=<name>", and others simply with "-k <name>".
-  Why are their two methods for KEY naming, and does one have a distinct meaning, or precedence, over the other?
-  Are their some 'rule' types where '-k' is appropriate, whereas '-F key=" is not, thus they are not truly 100% interchangeable?
-  If both methods ARE equivalent throughout ALL of the audit.rules content, would it be reasonable to standardize on one method in v3.0.x of your rules going forward?


3.  For a RHEL 7.x (and even 8.x) system where the hardware is x86_64 and there is no reasonable expectation to install or operate 'ANY' 32bit software, is there any value, or system performance penalty, to totally eliminating all 'b32' rules?


4.  On the grub/kernel commandline, I can add:  'audit=1' -and- 'audit_backlog_limit=####'.  I looked for solutions to address the issue I was having, and found one here:  https://access.redhat.com/solutions/19327; I found another somewhat helpful reference here:  https://blog.siphos.be/2015/05/audit-buffering-and-rate-limiting; though it doesn't make good recommendations for the kernel parameter sizing (if that is a good thing to do in RHEL 7/RHEL 8).
-  Is there good relevance in RHEL 7, or RHEL 8 to adding this option to the grub/kernel commandline?
-  Is there an upper-limit in setting the number?
-  What is the correlation of this grub/kernel item, to the '-b ####' rule in /etc/audit/rules.d/audit.rules?  Are they (or should they be treated as) mutually exclusive?
-  In the 2nd reference, what process do you suggest for me to determine optimal values for 'kernel.printk_ratelimit'  -and -  'kernel.printk_ratelimit_burst', as well as for grub/kernel 'audit_backlog_limit=####' and audit.rules '-b ####'?
-  This link also seems relevant to the sysctl param's valuations:  https://topic.alibabacloud.com/a/linux-system-log-__ratelimitn-callbacks-suppressed_1_16_30164105.html
-  Does values for 'kernel.printk_ratelimit = 1';   -and-   'kernel.printk_ratelimit_burst = 1024' seem reasonable?


Thank you.

R,
-Joe