Linux-Fsdevel Archive on lore.kernel.org
help / color / mirror / Atom feed
* fanotify feature request FAN_MARK_PID
@ 2020-08-17 16:08 Tycho Kirchner
  2020-08-17 17:02 ` Amir Goldstein
  0 siblings, 1 reply; 5+ messages in thread
From: Tycho Kirchner @ 2020-08-17 16:08 UTC (permalink / raw)
  To: amir73il, mbobrowski, linux-fsdevel

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




^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2020-08-28  8:46 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-08-17 16:08 fanotify feature request FAN_MARK_PID Tycho Kirchner
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

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