fanotify Support?

[e-dant]

Nice filesystem watcher!

You may be able to use this: https://github.com/e-dant/watcher-rs-cli/blob/next/src/watcher/adapter/linux/fanotify.rs

If you're looking for fanotify support in this project.

The relative lack of fanotify backends in filesystem watchers makes the (many) caveats and footguns in fanotify less obvious. This can increase the implementation overhead in unexpected ways. These footguns are not always documented. For example, the variable-length data given to userspace in an event's metadata is not uniformly reported according to the metadata's flags. Moreover, Rust's libc types for fanotify, and file handles, are sometimes broken, or just missing. Albeit, the need to calculate pointer offsets from kernel-internal data structures might be absent from Rust's libc crate for good reasons, but the data and metadata types are more mysteriously missing some of the variable-length fields.

The relative lack of use of fanotify also make the benefits less obvious. Support for "special" kinds of paths in fanotify has more support than most alternatives. On Linux, there are some event types and paths that cannot be reported otherwise.

If fanotify support is on the horizon, I'd be happy to help contribute. Perhaps someone more experience with notify-rs can help guide this into a backend?

[0xpr03]

I don't see how this fits into notify. Notify is first of all a cross-platform way to subscribe to file events. And fanotify requires root privileges, making it less interesting to use for that. The other problem is that if you're already using fanotify (and thus providing root access), you probably also expect to use the access deny options from fanotify (realtime filtering for AV), which has kind of no place in the notify API and doesn't fit with the other backends.

On top of that it's not as easy to get right, as you've written yourself, so it ads more technical depth while providing questionable feature gains.

I'd suggest making a crate for that, which specializes on anti-virus / access control stuff like this.

[0xpr03]

Replacing inotify is probably also not an option, as fanotify doesn't feature many events in older kernel versions, which are still LTS.

If I'm missing anything, feel free to correct me.

[0xpr03]

As a result, it does not catch remote events that occur on network filesystems

Sounds like it also still doesn't help for NTFS or WSL mounts ?

Fanotify monitoring of directories is not recursive: to monitor
subdirectories under a directory, additional marks must be
created. The FAN_CREATE event can be used for detecting when a
subdirectory has been created under a marked directory. An
additional mark must then be set on the newly created
subdirectory

So it's not really recursive, as opposed to the windows API.

[e-dant]

I don't have much skin in the game. Wouldn't want your project to take on work that doesn't fit.

As for network filesystems -- are NTFS and WSL mounts networked? Either way, it's not clear to me either if events from a mounted directory, such as mounts across a container boundary, would be reported. Could probably test that with minimal effort if there's interest.

As for recursion -- it's interesting, yes and no. There are a few modes fanotify can operate in. If watching by mount points, it's recursive. If watching by paths, it's roughly the same as inotify's process; per-directory marks.

I also don't think it's an either/or between fanotify and inotify.

The root permissions are somewhat muddled. You shouldn't need root permissions for most of the API, but I've found that the combination of flags requiring different permissions is under-documented. My project settles on requiring root permissions because of that.

The cases a user is running as root (and wants to run a filesystem watcher as root) are probably:

• In some containers
• In some daemons

So, probably not the majority of use-cases, but also probably worth consideration.

Again -- I don't have too much skin in the game. I'm not tuned in to the constraints, design goals and maintenance priorities of this project.

[e-dant]

Another thing to note, in re. the fanotify's reporting, is that you can configure fanotify to receive events before or after they occur.

I wouldn't say that fanotify's only use-case is as an auditing tool.

[e-dant]

One case which I've found fanotify indispensable is when I need to watch an entire filesystem.

Inotify and kqueue quickly run out of file descriptors. Fanotify doesn't (if watching paths, a flag can be set for unlimited marks; if watching mounts, everything is reported -- so, either way).

[e-dant]

(Side question: How does notify-rs work around open file descriptor limits? I haven't found a good solution.)

[0xpr03]

How does notify-rs work around open file descriptor limits

It doesn't. Use the pollwatcher or increase the limits, that's all you can do.

Hmm, I could imagine adding this as a backend behind a feature flag for now, if people really want to use it. In the same way all the other APIs currently are (kqueue, fsevents, inotiy..). You can look at the inotify implementation to get an idea of how this fits in the existing traits. Note that this is the first time I've heard from this requirement for notify.