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? > 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? Say, security policy applies to /usr/bin/* so lsm suppose to act on all files and subdirs in there. How fanotify helps ?
