From: "J. R. Okajima" <hooanon05g@gmail.com>
To: jack@suse.cz, amir73il@gmail.com
Cc: linux-fsdevel@vger.kernel.org
Subject: fanotify: FAN_OPEN_EXEC_PERM stops invoking the commands
Date: Sun, 06 Jun 2021 01:04:31 +0900 [thread overview]
Message-ID: <1461.1622909071@jrobl> (raw)
Hello,
fanotify has a neat feature called "perm event" which makes the listener
process can allow/deny the access to a file by another process.
But it doesn't work well if
- FAN_OPEN_EXEC_PERM event is monitored
- the other process's executable is monitored by the listener process
The scenario is like this.
- fanotify_init(O_RDWR)
- fanotify_mark(FAN_OPEN_EXEC_PERM, "/dirA")
- read() the event via fanotify_fd. it blocks.
and run "/dirA/a.out" executable on another terminal.
Then
- FAN_OPEN_EXEC_PERM event is enqueued
- the listener process tries reading the event
- fanotify tries preparing FD by opening the executable. the flag to
open is the one given to fanotify_init(). it is O_RDWR here.
- we cannot open the running executable with O_RDWR flag.
- fanotify forces FAN_DENY as a response to the perm event.
- the listener read() gets ETXTBSY from fanotify.
As a result,
- the listener process cannot get the perm event, and cannot write
the response FAN_ALLOW either.
- a.out process fails to start (EPERM) because fanotify sets FAN_DENY.
In other words, fanotify stops invoking a.out even if the listener
process wants to allow it.
That is bad.
My question is,
Why do we need to reuse full fsnotify_group->fanotify_data.f_flags when
opening the executable? I can understand people may want to set
O_NONBLOCK or O_CLOEXEC flags. But how about RW flags? Isn't it good
enough to force opening fanotify_event_metadata.fd with O_RDONLY?
Passing O_RDWR to fanotify_init() should be kept in order to make
fanotify_fd writable.
J. R. Okajima
next reply other threads:[~2021-06-05 16:05 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-05 16:04 J. R. Okajima [this message]
2021-06-05 17:50 ` fanotify: FAN_OPEN_EXEC_PERM stops invoking the commands Amir Goldstein
2021-06-05 18:25 ` hooanon05g
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=1461.1622909071@jrobl \
--to=hooanon05g@gmail.com \
--cc=amir73il@gmail.com \
--cc=jack@suse.cz \
--cc=linux-fsdevel@vger.kernel.org \
/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;
as well as URLs for NNTP newsgroup(s).