Hey Jan/Amir/Christian,
This is the RFC patch series for adding pidfd support to the fanotify
API.
tl;dr rather than returning a pid within struct
fanotify_event_metadata, a pidfd is returned instead when fanotify has
been explicitly told to do so via the new FAN_REPORT_PIDFD flag.
The main driver behind returning a pidfd within an event instead of a
pid is that it permits userspace applications to better detect if
they've possibly lost a TOCTOU race. A common paradigm among userspace
applications that make use of the fanotify API is to crawl /proc/<pid>
upon receiving an event. Userspace applications do this in order to
further ascertain contextual meta-information about the process that
was responsible for generating the filesystem event. On high pressure
systems, where pid recycling isn't uncommon, it's no longer considered
as a reliable approach to directly sift through /proc/<pid> and have
userspace applications use the information contained within
/proc/<pid> as it could, and does, lead to program execution
inaccuracies.
Now when a pidfd is returned in an event, a userspace application can:
a) Obtain the pid responsible for generating the filesystem event
from the pidfds fdinfo.
b) Detect whether the userspace application lost the procfs access
race by sending a 0 signal on the pidfd and checking the return
value. A -ESRCH is indicative of the userspace application
losing the race, meaning that the pid has been recycled.
Matthew Bobrowski (2):
pidfd_create(): remove static qualifier and declare pidfd_create() in
linux/pid.h
fanotify: Add pidfd support to the fanotify API
fs/notify/fanotify/fanotify_user.c | 33 +++++++++++++++++++++++++++---
include/linux/fanotify.h | 2 +-
include/linux/pid.h | 1 +
include/uapi/linux/fanotify.h | 2 ++
kernel/pid.c | 2 +-
5 files changed, 35 insertions(+), 5 deletions(-)
--
2.31.1.368.gbe11c130af-goog
/M
