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

[Paul Moore]

On Wed, Sep 16, 2026 at 4:48 AM Christian Brauner <brauner@xxxxxxxxxx> wrote:
> 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@xxxxxxxxxx> 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@xxxxxxxxxxxxxx> wrote:
> > > > >
> > > > > On Sun, Sep 13, 2026 at 7:25 PM Alexei Starovoitov
> > > > > <alexei.starovoitov@xxxxxxxxx> wrote:
> > > > > > On Sun, Sep 13, 2026 at 12:41 PM Paul Moore <paul@xxxxxxxxxxxxxx> wrote:
> > > > > > > On Sat, Sep 12, 2026 at 3:33 PM Alexei Starovoitov
> > > > > > > <alexei.starovoitov@xxxxxxxxx> 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@xxxxxxxxxxxx/
> > > > > >
> > > > > > 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@xxxxxxxxxxxxxx/
> >
> > 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.

If my comments came across as a lecture, you are likely hearing the
frustration of having to revisit a topic where my past requests for
some mutual understanding on process have been ignored or silently
discarded.  If you have been offended by the tone of my comments,
please understand that I have been offended by your actions.

> 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.

Regardless of how we got here, I think we can agree that we both want
to sort this out and find a way to work better moving forward, yes?

My request is the same as it ever was: please don't merge code for one
of the subsystems I am responsible for maintaining without an explicit
ACK or reviewed-by tag on the patch{set} you are merging.  As for who
merges what, and where, considering past history, I think it's
probably going to be difficult to find a single generic rule that will
make both of us happy.  Perhaps we can simply agree to have a
discussion about where the patches are merged when we are
ACK'ing/Review'ing them?  In other words, there would be no default
merging tree/branch, the default would be for us to discuss how best
to get the changes in Linus' tree on a per-patchset basis.

I'm sure you have your own thoughts, but I figured it would be helpful
to get something out here as a start.

-- 
paul-moore.com