> > 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. > > > > 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 <amir73il@xxxxxxxxx> 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
