<html><body> <tt>> 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. </tt> <tt>> 1. -D (delete all rules) doesn't delete any rules I see this problem also. </tt> <tt>I'm seeing lots of strange behavior when I updated to this new kernel.</tt> <tt># auditctl -a entry,always -F arch=b32 -S chmod</tt> <tt>No rules</tt> <tt># auditctl -l</tt> <tt>No rules</tt> <tt># auditctl -D</tt> <tt>AUDIT_LIST: entry always a1=4 (0x4) syscall=access</tt> <tt>AUDIT_LIST: entry always a1=3 (0x3) syscall=access</tt> <tt>AUDIT_LIST: entry never a1=4 (0x4) syscall=access</tt> <tt>AUDIT_LIST: entry always syscall=chmod</tt> <tt>AUDIT_LIST: entry never syscall=chmod</tt> <tt>AUDIT_LIST: entry always arch=3221225534 (0xc000003e) syscall=semget</tt> <tt>AUDIT_LIST: entry never arch=3221225534 (0xc000003e) syscall=semget</tt> <tt>AUDIT_LIST: entry always arch=3221225534 (0xc000003e) syscall=semget</tt> <tt>AUDIT_LIST: entry never arch=3221225534 (0xc000003e) syscall=semget</tt> <tt>AUDIT_LIST: entry always arch=3221225534 (0xc000003e) syscall=semget</tt> <tt>AUDIT_LIST: entry never arch=3221225534 (0xc000003e) syscall=semget</tt> <tt>AUDIT_LIST: entry always syscall=chmod</tt> <tt>> > 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 </tt><tt>kernel-2.6.9-5.0.3.EL.audit.24 and </tt><tt>audit-0.7.1-1. </tt> <tt>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.</tt> <tt>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,</tt> <tt>I got a kernel panic when trying to boot.</tt> <tt> Kernel Panic -not syncing: kernel/auditfs.c:439</tt> <tt> spin_is_locked on uninitalized spinlock</tt> <tt>-debbie</tt> </body></html>