On Fri, 8 Nov 2019 13:39:58 -0700
"John T Olson" <jtolson(a)us.ibm.com> wrote:
Greetings,
I have the following 2 audit rules set up:
-a always,exit -F arch=b64 -S all -F exit=-EACCES -F dir=/gpfs/fs1
-a always,exit -F arch=b64 -S all -F exit=-EPERM -F dir=/gpfs/fs1
I have a directory structure like the following:
(13:15:26) zippleback-vm1:~ # ls -la /gpfs/fs1/test/
total 257
drwx------. 3 root root 4096 Nov 7 12:46 .
drwxr-xr-x. 15 root root 262144 Nov 7 12:50 ..
drwx------. 2 root root 4096 Nov 7 12:46 test2
Essentially, directory "/gpfs/fs1/test/" is owned by root and has
permissions 700. The subdirectory underneath it (with
path /gpfs/fs1/test/test2) is also owned by root and has permissions
700.
When I have a non-root user attempt to list the contents of directory
"/gpfs/fs1/test/" I receive an audit message for the denied access.
However, when the non-root user attempts to list the contents of the
subdirectory (/gpfs/fs1/test/test2), there is no audit message
generated. Does anyone know why this is and how I get audit messages
in both cases?
Yes, the reason is because the path did not resolve so audit never saw
it. This has been this way for quite some time. In the past, it was
said because the path never resolved, a PATH record with all attributes
could not be generated. I have mentioned to kernel maintainers, that
the path is available as a syscall argument. While a full PATH record
cannot be generated with file attributes, an abbreviated one could be
generated. So, far...no one has saw this as a big enough problem to
fix. Personally, I think it should be fixed.
-Steve