Description
Hello everyone!
On Linux, there is the filesystem monitoring facility called fanotify, that allows monitoring (and sometimes blocking) filesystem operations using a fanotify group file descriptor. For most events, the file may be identified with a file descriptor -- that is, when the watching process reads an event notification from fanotify file descriptor, a FD pointing to the target file is opened in the watching process, which can be used to identify the file and operate on it. However, some fanotify operation modes require a fanotify group that identifies files and directories by file handles -- opaque byte arrays that can be passed to open_by_handle_at() to retrieve a file descriptor for the target. I've made a crate with bindings to name_to_handle_at() and open_by_handle_at() system calls, which encapsulates the file handle and allows to work safely with it (however, since the size of a file handle is not known before requesting it, and requesting it consists of two name_to_handle_at() calls -- the first is to get the requested size and the second is to obtain the handle itself -- my crate stores the file handle on the heap and the LinuxFileHandle only stores a Vec pointing to the handle) -- something similar could be done for the fanotify module.
It should be noted that open_by_handle_at() requires CAP_DAC_READ_SEARCH to be effective for the calling process -- therefore, fanotify-based apps that want to identify files by their handles should be granted it and keep it at least for the lifetime of the fanotify group (unlike CAP_SYS_ADMIN, which may be dropped after calling fanotify_init(), as long as the application doesn't plan to use it for calling fanotify_init() for second time or use other features that require that capability, such as mounting filesystems).