> 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