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:
https://github.com/tycho-kirchner/shournal
For a more scientfic introduction please take a look at
Bashing irreproducibility with shournal
https://doi.org/10.1101/2020.08.03.232843
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
i.
Some applications (gdb and possibly others) do not play well in
controlling applications across mount namespaces (see also
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=940563)
ii.
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).
iii.
setuid-binaries always impose a security-risk.
I imagine e.g. the following syscalls:
1.
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.
2.
Use fanotify_mark to remove a PID from the notification group.
fanotify_mark(fan_fd, FAN_MARK_REMOVE | FAN_MARK_PID, 0, pid, NULL);
3.
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 |
FAN_MARK_MOUNT_REC, mask, AT_FDCWD, path);
Thanks in Advance
Kind Regards
Tycho Kirchner
