I re-tested today with the user space patch applied. I thought I
would post my results in case they are different from what you found.
1. -D (delete all rules) doesn't delete any rules
I see
this problem also.
I'm seeing lots of strange behavior when I updated to this new kernel.
# auditctl -a entry,always -F arch=b32 -S chmod
No rules
# auditctl -l
No rules
# auditctl -D
AUDIT_LIST: entry always a1=4 (0x4) syscall=access
AUDIT_LIST: entry always a1=3 (0x3) syscall=access
AUDIT_LIST: entry never a1=4 (0x4) syscall=access
AUDIT_LIST: entry always syscall=chmod
AUDIT_LIST: entry never syscall=chmod
AUDIT_LIST: entry always arch=3221225534 (0xc000003e) syscall=semget
AUDIT_LIST: entry never arch=3221225534 (0xc000003e) syscall=semget
AUDIT_LIST: entry always arch=3221225534 (0xc000003e) syscall=semget
AUDIT_LIST: entry never arch=3221225534 (0xc000003e) syscall=semget
AUDIT_LIST: entry always arch=3221225534 (0xc000003e) syscall=semget
AUDIT_LIST: entry never arch=3221225534 (0xc000003e) syscall=semget
AUDIT_LIST: entry always syscall=chmod
I see these bugs with the patched version of both audit-0.6.10 and
audit-0.7.1 running with the audit.24 kernel. I haven't tried the
2.6.12 kernel yet.
I am using kernel-2.6.9-5.0.3.EL.audit.24 and audit-0.7.1-1.
I've used audit-0.7.1-1 with kernel-2.6.9-5.0.3.EL.audit.20 and didn't see
this strange behavior.
I wanted to try kernel-2.6.9-5.0.3.EL.audit.23 but when I tried installing
kernel-2.6.9-5.0.3.EL.audit.23,
I got a kernel panic when trying to boot.
Kernel Panic -not syncing: kernel/auditfs.c:439
spin_is_locked on uninitalized spinlock
-debbie