Overview: Under Linux a file system object may be accessible under different paths. E.g. a path may be remounted using mount --bind. When watching a mount a fanotify listener receives an event only if the file system object was touched using the same mount. E.g. given a mount /home watched by a fanotify listener. Now remount with sudo mount /home /opt --bind nano /opt/user/file The fanotify listener will not discover that /home/user/file has been modified. Given that the fanotify was introduced as a basis for virus scanning this has to be considered a bug. The background is that a list of marks for a mount is kept in the vfsmount structure. It would be preferable to the attach the list of marks for mounts to the superblock. Steps to Reproduce: Given mount /home. Compile the example code from the fanotify.7 manpage. Monitor mount /home using the compiled code. sudo mount /home /opt --bind nano /opt/user/file Actual Results: No events are reported for /opt/user/file Expected Results: Events should be reported.
I believe this was a deliberate design choice. Eric, do you remember why we ended up tracking events per mountpoint and not per superblock?
(In reply to Jan Kara from comment #1) > I believe this was a deliberate design choice. Eric, do you remember why we > ended up tracking events per mountpoint and not per superblock? I guess referring to mounts in the API is fine. Anyway there is no object superblock in user space. My suggestion is simply to determine mounts by analyzing the superblock referenced by the dentry instead of analyzing a path structure. So what I suggest is: for each mount of dentry-superblock { if mount-root is ancestor of dentry-inode { for each fanotify-group of mount { create event; } } }