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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.