Re: fanotify feature request FAN_MARK_PID

[Amir Goldstein <amir73il@gmail.com>]

> Any further help is appreciated.
>

A patch along those line (fill in the missing pieces) looks useful to me.
It could serve a use case where applications are using fanotify filesystem
mark, but developer would like to limit those application's scope inside
"system containers".

Perhaps an even more useful API would be FAN_FILTER_MOUNT_NS.
FAN_FILTER_PID_NS effectively means that kernel will drop events
that are expected to report pid 0.
FAN_FILTER_MOUNT_NS would mean that kernel will drop events that
are expected to report an fd, whose /proc/<pid>/fd/<fd> symlink cannot
be resolved (it shows "/") because the file's mount is outside the scope
of the listener's mount namespace.

The burden of proof that this will be useful is still on you ;-)

Thanks,
Amir.

--- a/fs/notify/fanotify/fanotify.c
+++ b/fs/notify/fanotify/fanotify.c
@@ -685,6 +685,11 @@ static int fanotify_handle_event(struct
fsnotify_group *group, u32 mask,

        pr_debug("%s: group=%p mask=%x\n", __func__, group, mask);

+       /* Interested only in events from group's pid ns */
+       if (FAN_GROUP_FLAG(group, FAN_FILTER_PID_NS) &&
+           !pid_nr_ns(task_pid(current), group->fanotify_data.pid_ns))
+               return 0;
+
        if (fanotify_is_perm_event(mask)) {
                /*
                 * fsnotify_prepare_user_wait() fails if we race with mark