> 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
