Re: [RFC PATCH 0/9] Landlock supervise: a mechanism for interactive permission requests

[Song Liu <song@kernel.org>]

On Tue, Mar 11, 2025 at 3:03 PM Tingmao Wang <m@maowtm.org> wrote:
[...]
> >
> > I think there is a fundamental difference between LSM hooks and fsnotify,
> > so putting fsnotify behind some LSM hooks might be weird. Specifically,
> > LSM hooks are always global. If a LSM attaches to a hook, say
> > security_file_open, it will see all the file open calls in the system. On the
> > other hand, each fsnotify rule only applies to a group, so that one fanotify
> > handler doesn't touch files watched by another fanotify handler. Given this
> > difference, I am not sure how fsnotify LSM hooks should look like.
> >
> > Does this make sense?
>
> To clarify, I wasn't suggesting that we put one hook _behind_ another
> ("behind" in the sense of one calling the other), just that the place
> that calls the new fsnotify_name_perm/fsnotify_rename_perm hook (in
> Amir's WIP branch) could also be made to call some new LSM hooks in
> addition to fsnotify (i.e. security_pathname_create/delete/rename).
>
> My understanding of the current code is that VFS calls security_... and
> fsnotify_... unconditionally, and the fsnotify_... functions figure out
> who needs to be notified.

Yes, VFS calls security_* and fsnotify_* unconditionally. In this sense,
fsnotify can be implemented as a LSM. But fsnotify also supports some
non-security use cases. So it will be weird to implement it as a LSM.

Thanks,
Song

[...]