> On Nov 14, 2024, at 4:41 PM, Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> wrote: > > On Thu, Nov 14, 2024 at 3:02 PM Song Liu <songliubraving@xxxxxxxx> wrote: >> >> >> >>> On Nov 14, 2024, at 12:14 PM, Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> wrote: >>> >>> On Thu, Nov 14, 2024 at 12:44 AM Song Liu <song@xxxxxxxxxx> wrote: >>>> >>>> + >>>> + if (bpf_is_subdir(dentry, v->dentry)) >>>> + ret = FAN_FP_RET_SEND_TO_USERSPACE; >>>> + else >>>> + ret = FAN_FP_RET_SKIP_EVENT; >>> >>> It seems to me that all these patches and feature additions >>> to fanotify, new kfuncs, etc are done just to do the above >>> filtering by subdir ? >>> >>> If so, just hard code this logic as an extra flag to fanotify ? >>> So it can filter all events by subdir. >>> bpf programmability makes sense when it needs to express >>> user space policy. Here it's just a filter by subdir. >>> bpf hammer doesn't look like the right tool for this use case. >> >> Current version is indeed tailored towards the subtree >> monitoring use case. This is mostly because feedback on v1 >> mostly focused on this use case. V1 itself actually had some >> other use cases. > > like? samples/fanotify in v1 shows pattern that matches file prefix (no BPF). selftests/bpf in v1 shows a pattern where we propagate a flag in inode local storage from parent directory to newly created children directory. > >> In practice, fanotify fastpath can benefit from bpf >> programmability. For example, with bpf programmability, we >> can combine fanotify and BPF LSM in some security use cases. >> If some security rules only applies to a few files, a >> directory, or a subtree, we can use fanotify to only monitor >> these files. LSM hooks, such as security_file_open(), are >> always global. The overhead is higher if we are only >> interested in a few files. >> >> Does this make sense? > > Not yet. > This fanotify bpf filtering only reduces the number of events > sent to user space. > How is it supposed to interact with bpf-lsm? Ah, I didn't explain this part. fanotify+bpf fastpath can do more reducing number of events sent to user space. It can also be used in tracing use cases. For example, we can implement a filetop tool that only monitors a specific directory, a specific device, or a specific mount point. It can also reject some file access (fanotify permission mode). I should have showed these features in a sample and/or selftest. > Say, security policy applies to /usr/bin/* > so lsm suppose to act on all files and subdirs in there. > How fanotify helps ? LSM hooks are always global. It is up to the BPF program to filter out irrelevant events. This filtering is sometimes expensive (match d_patch) and inaccurate (maintain a map of target inodes, etc.). OTOH, fanotify has built-in filtering before the BPF program triggers. When multiple BPF programs are monitoring open() for different subdirectories, fanotify based solution will not trigger all these BPF programs for all the open() in the system. Does this answer the questions? Thanks, Song
