From: seth@soulintheshell.com
To: audit@vger.kernel.org, Steve Grubb <sgrubb@redhat.com>
Subject: Failure to set a watch on a non existing directory
Date: Wed, 04 Nov 2026 19:50:15 +0100 [thread overview]
Message-ID: <8733tgfn2w.fsf@soulintheshell.com> (raw)
Hello,
I reported a behavior that seemed anormal to the auditd maintainer:
https://lists.linux-audit.osci.io/archives/list/linux-audit@lists.linux-audit.osci.io/thread/KOPL2QPINU6F6WVSKN7U3LRLVIXEQYLZ/
The behavior is the impossibility to make a watch on a directory with
`auditctl -F dir=$path` while it is possible with `auditctl -w $path`.
This is problematic as directories may not exists yet when auditd is
initialized (eg: from kernel command line), and the `-w` rules are
marked as deprecated by auditctl.
Here a few tests that illustrate the problem:
- nonexisting path
#+begin_src bash
auditctl -a always,exit -F arch=b64 -F path=/nonexisting_path -F perm=wa
auditctl -a always,exit -F path=/nonexisting_path -F perm=wa
auditctl -l
#+end_src
#+RESULTS:
: perm used without an arch is slower
: perm used without an arch is slower
: -a always,exit -F arch=b64 -S open,bind,truncate,ftruncate,rename,mkdir,rmdir,creat,link,unlink,symlink,chmod,fchmod,chown,fchown,lchown,mknod,acct,swapon,quotactl,setxattr,lsetxattr,fsetxattr,removexattr,lremovexattr,fremovexattr,openat,mkdirat,mknodat,fchownat,unlinkat,renameat,linkat,symlinkat,fchmodat,fallocate,renameat2,openat2 -F path=/nonexisting_path -F perm=wa
: -w /nonexisting_path -p wa
- nonexisting_dir
This will error:
#+begin_src bash
auditctl -a always,exit -F dir=/nonexisting_dir -F perm=wa -k nonexisting
#+end_src
#+RESULTS:
: perm used without an arch is slower
: perm used without an arch is slower
: Error sending add rule data request (No such file or directory)
: There was an error while processing parameters
#+begin_src bash
auditctl -a always,exit -F arch=b64 -F dir=/nonexisting_dir -F perm=wa -k nonexisting_dir
auditctl -l
#+end_src
#+RESULTS:
: Error sending add rule data request (No such file or directory)
: There was an error while processing parameters
Steve Grubb suggested that the issue may be to watch at /, but I don't think so:
#+begin_src bash
auditctl -a always,exit -F arch=b64 -F dir=/root/.config/nonexisting_dir -F perm=wa -k nonexisting_dir
#+end_src
#+RESULTS:
: Error sending add rule data request (No such file or directory)
: There was an error while processing parameters
This will not error:
#+begin_src bash
auditctl -w /root/.config/nonexisting_dir -F perm=wa -k nonexisting_dir
#+end_src
#+RESULTS:
: Old style watch rules are slower
: perm used without an arch is slower
: perm used without an arch is slower
: -w /root/.config/nonexisting_dir -p rwxa -p wa -k nonexisting_dir
Additionally here is quote from Steve Grubb about tracing the execution
of auditctl:
#+begin_quote
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.
#+end_quote
-Seth
reply other threads:[~2026-11-04 18:52 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8733tgfn2w.fsf@soulintheshell.com \
--to=seth@soulintheshell.com \
--cc=audit@vger.kernel.org \
--cc=sgrubb@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox