[RFC/PATCH v2 bpf-next fanotify 7/7] selftests/bpf: Add test for BPF based fanotify fastpath handler

[Alexei Starovoitov]

On Thu, Nov 14, 2024 at 3:02 PM Song Liu <songliubraving at meta.com> wrote:
>
>
>
> > On Nov 14, 2024, at 12:14 PM, Alexei Starovoitov <alexei.starovoitov at gmail.com> wrote:
> >
> > On Thu, Nov 14, 2024 at 12:44 AM Song Liu <song at kernel.org> 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 ?