Linux-Fsdevel Archive on
help / color / mirror / Atom feed
From: Tycho Kirchner <>
Subject: fanotify feature request FAN_MARK_PID
Date: Mon, 17 Aug 2020 18:08:43 +0200	[thread overview]
Message-ID: <> (raw)

Dear Amir Goldstein,

Dear Matthew Bobrowski,

Dear developers of the kernel filesystem,

First of all, thanks for your effort in improving Linux, especially your 
work regarding fanotify, which I heavily use in one of my projects:

For a more scientfic introduction please take a look at
Bashing irreproducibility with shournal

I wanted to kindly ask you, whether it is possible for you to add 
another feature to fanotify, that is reporting only events of a PID or 
any of its children.
This would be very useful, because especially in the world of 
bioinformatics there is a huge need to automatically and efficiently 
track file events on the shell, that is, you enter a command on the 
shell (bash) and then track, which file events were modified by the 
shell or any of its child-processes.
Right now this is realized in shournal by joining a mount namespace 
which is unique for each entered command and listening to file events of 
these mountpoints using fanotify.
This works great so far in most cases, but joining another mount 
namespace is actually something I would like to avoid, because

Some applications (gdb and possibly others) do not play well in 
controlling applications across mount namespaces (see also

Joining the mount-namespace has performance-implications, because a 
setuid-binary, which joins the mount-namespace, must be called 
beforehand. Further, care must be taken to preserve the environment (env).

setuid-binaries always impose a security-risk.

I imagine e.g. the following syscalls:

Use fanotify_mark to restrict the fanotify notification group to a 
specific PID, optionally marking forked children as well.
fanotify_mark(fan_fd, FAN_MARK_ADD | FAN_MARK_PID, FAN_EVENT_ON_CHILD, 
pid, NULL);
// FAN_EVENT_ON_CHILD -> additional meaning: also forked child processes.

Use fanotify_mark to remove a PID from the notification group.
fanotify_mark(fan_fd, FAN_MARK_REMOVE | FAN_MARK_PID, 0, pid, NULL);

When reading from a fan_fd, which is marked for PID's which have all 
ended or were removed, return e.g. ENOENT.

Independent of that it would be also useful, to be able to track 
applications, which unshare their mount namespace as well (e.g. 
flatpak). So in case a process, whose mount points are observed, 
unshares, the new mount id's should also be added to the same fanotify 
notification group. To preserve backwards compatibility I suggest 
introducing a new flag FAN_MARK_MOUNT_REC:
fanotify_mark(fan_fd, FAN_MARK_ADD | FAN_MARK_MOUNT | 

Thanks in Advance
Kind Regards
Tycho Kirchner

             reply	other threads:[~2020-08-17 17:43 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-17 16:08 Tycho Kirchner [this message]
2020-08-17 17:02 ` Amir Goldstein
2020-08-22 22:47   ` Tycho Kirchner
2020-08-23 13:04     ` Amir Goldstein
2020-08-28  8:46       ` Jan Kara

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \
    --subject='Re: fanotify feature request FAN_MARK_PID' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

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).