quoted

Well there is another way.
It is demonstrated in my demo with intoifywatch --fanotify --recursive.
It involved userspace iterating a subtree of interest to create fid->path
map.

Ok, so this seems to be

inotifytools_filename_from_fid()
-> if (fanotify_mark_type != FAN_MARK_FILESYSTEM)
           watch_from_fid()
   -> read_path_from(/proc/self/fd/w->dirfd)

Yes.

quoted

The fanotify recursive watch is similar but not exactly the same as the
old intoify recursive watch, because with inotify recursive watch you
can miss events.

With fanotify recursive watch, the listener (if capable) can setup a
filesystem mark so events will not be missed. They will be recorded
by fid with an unknown path and the path information can be found later
by the crawler and updated in the map before the final report.

Events on fid that were not found by the crawler need not be reported.
That's essentially a subtree watch for the poor implemented in userspace.

This is already a good improvement.
Honestly, having FAN_MARK_INODE workable unprivileged is already pretty

I'm not so sure why you say that, because unprivileged FAN_MARK_INODE
watches are pretty close in functionality to inotify.
There are only subtle differences.

great. In addition having FAN_MARK_MOUNT workable with idmapped mounts
will likely get us what most users care about, afaict that is the POC
in:
https://github.com/amir73il/linux/commit/f0d5d462c5baeb82a658944c6df80704434f09a1

Hmm, the problem is the limited set of events you can get from
FAN_MARK_MOUNT which does not include FAN_CREATE.

(I'm reading the source correctly that FAN_MARK_MOUNT works with
FAN_REPORT_FID as long as no inode event set in FANOTIFY_INODE_EVENTS is
set? I'm asking because my manpage - probably too old - seems to imply
that FAN_REPORT_FID can't be used with FAN_MARK_MOUNT although I might
just be stumbling over the phrasing.)

commit d71c9b4a5c6fbc7164007b52dba1de410d018292
Author: Amir Goldstein [off-list ref]
Date:   Mon Apr 20 21:42:56 2020 +0300

    fanotify_mark.2: Clarification about FAN_MARK_MOUNT and FAN_REPORT_FID

    It is not true that FAN_MARK_MOUNT cannot be used with a group
    that was initialized with flag FAN_REPORT_FID.
 ...

IOW, no FAN_CREATE, FAN_DELETE, FAN_MOVE

The technical reason for that is Al's objection to pass the mnt context
into vfs helpers (and then fsnotify hooks).

I think FAN_MARK_FILESYSTEM should simply stay under the s_userns_s
capable requirement. That's imho the cleanest semantics for this, i.e.
I'd drop:
https://github.com/amir73il/linux/commit/bd20e273f3c3a650805b3da32e493f01cc2a4763
This is neither an urgent use-case nor am I feeling very comfortable
with it.

The purpose of this commit is to provide FAN_CREATE, FAN_DELETE
FAN_MOVE events filtered by (an idmapped) mount.
I don't like it so much myself, but I have not had any better idea how to
achieve that goal so far.

There is another way though.
We can create a new set of hooks outside the vfs helpers that do have
the mnt context.

I have already created such a set for another POC [1].
In this POC I introduced three new events FS_MODIFY_INTENT,
FS_NAME_INTENT, FS_MOVE_INTENT, which I had no plans of
exposing to fanotify. Nor did I need the granularity of CREATE,
DELETE, RENAME event types (all collapsed into NAME_INTENT).

But if we hit a dead end, we can resort to this strategy.

Thanks,
Amir.

[1] https://github.com/amir73il/linux/commits/fsnotify_pre_modify