On Wednesday, July 22, 2026 5:38:46 AM Eastern Daylight Time seth--- via Linux-audit wrote: Yes. There are a couple reasons, the main one being performance. But the other reason being exact control over what is being watched. That goes back to exact control I mentioned above. I'd suggest to try again with a newer version. There may have been a problem in an older release that checked first. But under the hood, they do almost the same thing but use the exact same kernel attributes to place the watch. How they differ is that '-w' enables all syscalls. Six or seven years ago, someone noticed this was hurting performance. They slimmed down the syscalls enabled and found the system was faster. '-w' has always enabled all syscalls, so I only changed the syscall based watch to be slimmed down. The second reason is '-w' changes behavior based on '/' being at the end. If the target is a directory and does not have '/', it watches the directory's inode. That might not be obvious. If the target includes '/', then it watches the directory recursively. Since this is non-obvious or at least easily missed, the -F path= and -F dir= make it very obvious that they will do something differently. Both should do the same thing. I tested it using the 4.2 prerelease code and both forms accept non-existing files. I'd do it ASAP so that it is obvious in the rules what you really want it to watch. I have not set a deadline. But people really should move so that when that day comes, they have no surprises. But if nothing else, for the performance gain. Maybe I'll drop it around the 4.3 time frame? -Steve

On Thursday, July 23, 2026 3:44:37 AM Eastern Daylight Time seth(a)soulintheshell.com wrote: ok, so if we trace ^^^ that: rule goes into the kernel: sendto(4, [{nlmsg_len=1080, nlmsg_type=AUDIT_ADD_RULE, nlmsg_flags=NLM_F_REQUEST|NLM_F_ACK, nlmsg_seq=2, nlmsg_pid=0}, "\x04\x00\x00\x00\x02\x00\x00\x00\x03\x00\x00\x00\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff"...], 1080, 0, {sa_family=AF_NETLINK, nl_pid=0, nl_groups=00000000}, 12) = 1080 Answer back: recvfrom(4, [{nlmsg_len=1100, nlmsg_type=NLMSG_ERROR, nlmsg_flags=0, nlmsg_seq=2, nlmsg_pid=270500}, {error=-ENOENT, msg=[{nlmsg_len=1080, nlmsg_type=AUDIT_ADD_RULE, nlmsg_flags=NLM_F_REQUEST|NLM_F_ACK, nlmsg_seq=2, nlmsg_pid=0}, "\x04\x00\x00\x00\x02\x00\x00\x00\x03\x00\x00\x00\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff"...]}], 8988, MSG_PEEK|MSG_DONTWAIT, {sa_family=AF_NETLINK, nl_pid=0, nl_groups=00000000}, [12]) = 1100 Message the user: write(2, "Error sending add rule data requ"..., 63Error sending add rule data request (No such file or directory)) = 63 The kernel is returning ENOENT. It doesn't matter which form of watch. But what I tested yesterday is different: auditctl -a always,exit -F path=/tmp/nonexitent -F perm=wa -k nonexistent into the kernel: sendto(4, [{nlmsg_len=1084, nlmsg_type=AUDIT_ADD_RULE, nlmsg_flags=NLM_F_REQUEST|NLM_F_ACK, nlmsg_seq=2, nlmsg_pid=0}, "\x04\x00\x00\x00\x02\x00\x00\x00\x03\x00\x00\x00\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff"...], 1084, 0, {sa_family=AF_NETLINK, nl_pid=0, nl_groups=00000000}, 12) = 1084 Answer back no error recvfrom(4, [{nlmsg_len=36, nlmsg_type=NLMSG_ERROR, nlmsg_flags=NLM_F_CAPPED, nlmsg_seq=2, nlmsg_pid=271266}, {error=0, msg={nlmsg_len=1084, nlmsg_type=AUDIT_ADD_RULE, nlmsg_flags=NLM_F_REQUEST|NLM_F_ACK, nlmsg_seq=2, nlmsg_pid=0}}], 8988, MSG_PEEK|MSG_DONTWAIT, {sa_family=AF_NETLINK, nl_pid=0, nl_groups=00000000}, [12]) = 36 It does take paths that do not exist. So, there is a difference in behavior based on whether it is a path or directory. That might be worth the kernel folks looking deeper into. -Steve