Description of problem: On ppc64 in 32-bit mode, pread syscall is not audited correctly. The 4th argument (offset) is consistantly 0. Version-Release number of selected component (if applicable): 20070208.0 How reproducible: Always. Steps to Reproduce: 1. auditctl -a entry,always -F arch=b32 -S pread 2. echo "ABCDEFG" > /tmp/pread_data 3. Compile (gcc -m32) and execute the following: #include <errno.h> #include <fcntl.h> #include <sys/types.h> #include <sys/stat.h> #include <unistd.h> int main() { int fd; char buff[5]; fd = open("/tmp/pread_data",O_RDONLY); pread(fd, buff, 5, 1); close(fd); return 0; } 4. See audit record's a3 value. Actual results: type=SYSCALL msg=audit(1174939960.810:64974): arch=14 syscall=179 success=yes exit=5 a0=3 a1=10020b68 a2=5 a3=0 items=0 ppid=12033 pid=14190 auid=502 uid=503 gid=503 euid=503 suid=0 fsuid=503 egid=503 sgid=0 fsgid=503 tty=pts2 comm="ranges1_test" exe="/rhcc/lspp/tests/LTP/ltp-merged/testcases/audit/filters/ranges1_test" subj=abat_u:abat_r:abat_t:s0-s15:c0.c1023 key=(null) Expected results: type=SYSCALL msg=audit(1174939960.810:64974): arch=14 syscall=179 success=yes exit=5 a0=3 a1=10020b68 a2=5 a3=1 items=0 ppid=12033 pid=14190 auid=502 uid=503 gid=503 euid=503 suid=0 fsuid=503 egid=503 sgid=0 fsgid=503 tty=pts2 comm="ranges1_test" exe="/rhcc/lspp/tests/LTP/ltp-merged/testcases/audit/filters/ranges1_test" subj=abat_u:abat_r:abat_t:s0-s15:c0.c1023 key=(null)
Eric: Looks like not an LSPP blocker. WAD. But just how designed. Problem is passing a 64-bit offset to 32-bit userspace. Broken into regs 4 & 5, but only audit 4. Reg 4 is high order of offset.
This should probably be added to LSPP documentation like the other syscalls that had minor issues. I think we can close this bz.
There is still some discussion going on about if we should special case this syscall as I'm told was done apparently for networking and ipc. Thoughts on the security relevance of pread and pwrite to collect the offset would be of interest to see if such work would be useful.
Actualy is this working right on ppc64? When I just built WITHOUT the -m32 and I have 2 audit rules [root@ibm-js20-01 ~]# auditctl -a entry,always -F arch=b64 -S pread [root@ibm-js20-01 ~]# auditctl -a entry,always -F arch=b32 -S pread I got type=SYSCALL msg=audit(1175621755.531:13): arch=14 syscall=179 success=yes exit=5 a0=3 a1=ffffe8b0 a2=5 a3=0 items=0 pid=2597 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="pread_test" exe="/root/pread_test" which is most strange to me...
ok, ignore comment #5 for now as it seems the system i'm working isn't even rhel5 and doesn't even seem to have all the 64 bit libraries installed. /me goes to reinstall.
This issue will not be changed for the LSPP kernels as pread/pwrite are not deemed 'security relevant.' I'm going to verify my assumptions but for now it is coming off of the LSPP lists. I expect this bug to be closed shortly as "NOTABUG"
Development Management has reviewed and declined this request. You may appeal this decision by reopening this request.