Use of the auditd system to watch a directory via a symlink hardly triggers any logs. Here is the situation:
# pwd
/home/root/serverfault
# ls -l
total 4
drwxr-xr-x 2 root root 4096 Sep 1 15:12 dir
lrwxrwxrwx 1 root root 3 Sep 1 15:12 p -> dir
# auditctl -w /home/root/serverfault/p -p rwxa -k PX
I had the naive impression that anytime I would read/write a file inside the /home/root/serverfault/p
directory, logs would appear in /var/log/audit/audit.log
. But they don't.
Also, there is no audit log if I do:
# echo hello > /home/root/serverfault/p/hello.txt
I did some experimentation using strace to run ls
on few directories and evaluated the outputs with the information in the auditctl(8)
man page. One interesting line from strace
output that makes me think that audit logs should have been generated is:
open("/home/root/serverfault/p/", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
May be it did not because open(2)
follows symlinks by default. Logs get generated only when running ls
on the parent directory (/home/root/serverfault
in our case) of the path (argument given to -w
switch in auditctl
) being watched.
I realize that /home/root/serverfault/p
is not really a directory but a symlink. But weren't symlinks meant to be used such that they did not appear to exist? Overall, it seems that auditing directory changes via a symlink is not supposed to be done. Is this really the case?
Hmm,
There are no changes happening to the inode of the symlink file, as that is merely a file that points elsewhere. Add the watch to the directory the symlink points to, instead, or experiment with
-F path
related options, though, again, there are no changes happening to the inode of the symlink.