On Tue, Sep 19, 2023 at 9:17 AM Amir Goldstein <amir73il@xxxxxxxxx> wrote:
> This was just fixed by Ivan in commit:
> 0ce7c12e88cf ("kernfs: attach uuid for every kernfs and report it in fsid")
Indeed, nice to see this will soon be fixed.
> As my summary above states, it is correct that fanotify does not
> yet fully supersedes inotify, but there is a plan to go in this direction,
> hence, inotify is "being phased out" it is not Obsolete nor Deprecated.
I agree that if inotify is to be phased out, we should concentrate on fanotify.
I'm however somewhat disappointed with the complexity of the fanotify
API. I'm not entirely convinced that fanotify is a good successor for
inotify, or that inotify should really be replaced. The additional
features that fanotify has could have been added to inotify instead; I
don't get why this needs an entirely new API. Of course, I'm late to
complain, having just learned about (the unprivileged availability of)
fanotify many years after it has been invented.
System calls needed for one inotify event:
- read()
System calls needed for one fanotify event:
- read()
- (do some magic to look up the fsid -
https://github.com/martinpitt/fatrace/blob/master/fatrace.c implements
a lookup table, yet more complexity that doesn't exist with inotify)
- open() to get a file descriptor for the fsid
- open_by_handle_at(fsid_fd, fid.handle)
- readlink("/proc/self/fd/%d") (which adds a dependency on /proc being mounted)
- close(fd)
- close(fsid_fd)
I should mention that this workflow still needs a privileged process -
yes, I can use fanotify in an unprivileged process, but
open_by_handle_at() is a privileged system call - it requires
CAP_DAC_READ_SEARCH. Without it, I cannot obtain information on which
file was modified, can I?
There is FAN_REPORT_NAME, but it gives me only the name of the
directory entry; but since I'm watching a lot of files and all of them
are called "memory.events.local", that's of no use.
Or am I supposed to use name_to_handle_at() on all watched files to
roll my own lookup? (The name_to_hamdle_at() manpage doesn't make me
confident it's a reliable system call; it sounds like it needs
explicit support from filesystems.)
> > (By the way, what was not documented is that fanotify_init() can only
> > be used by unprivileged processes if the FAN_REPORT_FID flag was
[...]
> I find this documentation that was written by Matthew very good,
Indeed! That's my mistake, I missed this section.
> FAN_REPORT_FID is designed in a way to be almost a drop in replacement
> for inotify watch descriptors as an opaque identifier of the object, except that
> fsid+fhanle provide much stronger functionality than wd did.
How is it stronger?
