open record looks like openat

Steve Grubb <sgrubb(a)redhat.com&gt; writes: Thank you Steve. With this update, and bug fixes to my code, my analysis program completes without reporting internal inconsistencies. This usually means most of the bugs have been removed. I carefully studied the output of my analysis program, and found one particularly odd line of output. I traced it back to an interesting audit event in the raw log (syscall 5 is the open system call): type=SYSCALL msg=audit(1185450758.059:1699): arch=40000003 syscall=5 success=yes exit=0 a0=bfb9ec10 a1=241 a2=1b6 a3=4284b560 items=2 ppid=1 pid=22079 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) comm="broadcast" exe="/home/ramsdell/scm/polgen/src/daemon-example/broadcast" subj=user_u:system_r:unconfined_t:s0 key=(null) type=CWD msg=audit(1185450758.059:1699): cwd="/" type=PATH msg=audit(1185450758.059:1699): item=0 name="/tmp/" inode=4128769 dev=fd:00 mode=041777 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:tmp_t:s0 type=PATH msg=audit(1185450758.059:1699): item=1 name="/tmp/polgen_daemon.txt" inode=4128817 dev=fd:00 mode=0100640 ouid=500 ogid=500 rdev=00:00 obj=user_u:object_r:tmp_t:s0 Notice this event has two PATH records, whereas all of the many other open events I studied in my logs have one PATH record. It's as if the open system call can behave as the openat system call. I changed my analysis program to use the last PATH record to find the file name, so that the same code can be used to analyze open and openat system calls. John