Re: LSM boundaries. Was: [PATCH bpf-next v3 04/15] lsm: Add the bpf_lsm_policy_release kfunc and policy object destructor

[Christian Brauner <brauner@kernel.org>]

On Tue, Sep 15, 2026 at 09:48:59AM -0400, Paul Moore wrote:
> On Tue, Sep 15, 2026 at 9:00 AM Christian Brauner <brauner@kernel.org> wrote:
> > On Sun, Sep 13, 2026 at 07:24:14PM -0700, Alexei Starovoitov wrote:
> > > On Sun, Sep 13, 2026 at 5:10 PM Paul Moore <paul@paul-moore.com> wrote:
> > > >
> > > > On Sun, Sep 13, 2026 at 7:25 PM Alexei Starovoitov
> > > > <alexei.starovoitov@gmail.com> wrote:
> > > > > On Sun, Sep 13, 2026 at 12:41 PM Paul Moore <paul@paul-moore.com> wrote:
> > > > > > On Sat, Sep 12, 2026 at 3:33 PM Alexei Starovoitov
> > > > > > <alexei.starovoitov@gmail.com> wrote:
> > > > > > > On Fri Sep 11, 2026 at 10:26 PM PDT, Justin Suess wrote:
> > > > > > > >
> > > > > > > > If fs/, mm/, drivers/, net/, are permitted to have kfuncs, then why not
> > > > > > > > security/? kfuncs.rst doesn't seem to forbid this.
> > > > > > >
> > > > > > > because fs, mm, net see the value in bpf. bpf helps these subsytems
> > > > > > > to focus on their core technologies and moves policy decisions out of
> > > > > > > kernel and into bpf.
> > > > > > > while lsm people treat bpf as arch-enemy.
> > > > > >
> > > > > > It's amusing to read this when just this week we merged a patchset
> > > > > > into the LSM tree for the benefit of those writing BPF LSMs.  If you
> > > > > > look at the discussion around patch 2/2 you will even see a reasonable
> > > > > > exchange between Matt Bobrowski, a BPF LSM maintainer, and me about
> > > > > > the patch.  Alexei is obviously welcome to his own opinion, but I
> > > > > > would encourage those reading this thread to look beyond his comments.
> > > > > >
> > > > > > https://lore.kernel.org/linux-security-module/20260904-lsm-mount-idmaps-v3-0-920a1963675d@amutable.com/
> > > > >
> > > > > And that's an example of unacceptable land grab by LSM folks
> > > > > that I'm concerned about.
> > > >
> > > > I made sure that patchset was ACK'd or Reviewed-by'd a VFS maintainer,
> > > > a BPF LSM maintainer, and the Smack maintainer before merging (I
> > > > covered the LSM and SELinux parts).  You might want to double check
> > > > your definition of "land grab".
> > >
> > > You're still missing the point.
> > > Christian could have landed it via vfs tree with your ack for security/*.
> > > You have no power over lsm hook changes within vfs.
> >
> > Which tbf is generally how I like to handle thing especially since we
> > usually have a lot of changes. But I'm open to shared branches as well.
> >
> > So I think we naturally have to modify existing LSM hooks. But it's
> > shared pain. Since we use BPF LSM heavily in systemd we generally have
> > to absorb such growing pains as well.
> 
> I have no problem with topic branches that various trees can pull, but
> I do have an issue with the VFS tree merging patchsets that haven't
> been properly ACK'd as well as the VFS tree creating topic branches
> for patchsets that aren't primarily VFS changes.  See below:
> 
> https://lore.kernel.org/linux-security-module/CAHC9VhTE82bRRSXSUuMOdrfoMh=xOb5hDvqiKWzBKD1urab3hA@mail.gmail.com/
> 
> Christian, if you want us to move forward with topic branches in the
> LSM tree for LSM changes that touch fs/ code I'm happy to do that, but
> I need an acknowledgement from you that the behaviors mentioned above
> will be cleaned up in the future.

This is another instance where one of your mails around how to organize
process ends up reading like you're lecturing your peers. This is not
just my impression btw. That impression is shared by other subsystem
maintainers - including in your own.

This is a simple case where something got picked up that you didn't want
to have picked up yet. Plus, I haven't gotten around to reading this
yet. VFS isn't exactly a dormant subsystem.

The easy way is to just say "Hey, I don't think this is ready yet. Could
you please drop it. I also would like to quickly sync on how we want to
merge this.".

If another subsystems hooks into the vfs layer or filesystems that the
vfs trees maintain then the default will always be that the vfs layer
provides the shared tree to pull.