fanotify: Adding pidfd support to the fanotify API

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