[PATCH v6 0/8] lsm: Replace security_sb_mount with granular mount hooks

[Song Liu]

Hi Paul,

On Tue, Sep 29, 2026 at 8:41 AM Paul Moore <paul at paul-moore.com> wrote:
>
> On Tue, Sep 29, 2026 at 2:21 AM Song Liu <song at kernel.org> wrote:
> > On Mon, Sep 28, 2026 at 3:35 PM Paul Moore <paul at paul-moore.com> wrote:
> > [...]
> > > >
> > > > There is another question here. These new hooks do not have any in-tree
> > > > user at the moment. This appears to violate the "New LSM Hooks" policy
> > > > in [2]. Could you please give more specific guidance on this?
> > >
> > > There are LSMs which implement mount level access controls, you've
> > > been updating those in your patchset :)  I believe that some of those
> > > LSMs do have some (full? needs verification) coverage on the new mount
> > > API.  I would expect that a patchset that adds, or modifies the
> > > existing, mount hooks would also update those LSMs accordingly.  From
> > > what I've seen, you've done a good job updating the individual LSMs
> > > thus far, but if you have any questions or are unsure of what to do
> > > for any one LSM, please ask and I'm sure the associated devs will be
> > > happy to help.
> >
> > I don't think the scope here, adding hooks for fsopen, fsconfig, fsmount,
> > fspick, open_tree, open_tree_attr and mount_setattr and using them
> > properly in all LSMs, is a reasonable ask for a single patchset. Given
> > how much time this simple refactoring patchset has taken, I don't foresee
> > this work landing in any reasonable timeframe.
> >
> > Please consider reviewing this set and landing it before asking for more
> > work.
>
> [NOTE: dropped herton at canonical due to bounces]
>
> I suspect there is a misunderstanding regarding the new mount API and
> the LSM hooks.  I believe that we have all of the necessary LSM hooks
> already in place for the new mount API, but since I haven't looked at
> that in several years, verifying this would be good.  Beyond ensuring
> the hooks are still complete, I was suggesting that if you are going
> to create per-operation LSM hooks for the legacy mount API, it would
> be good if we had similar (same?) LSM hooks for the new mount API.
> Alternatively, if it doesn't make sense to have per-operation hooks
> with the new API, it would be good to document that in your patchset's
> commit descriptions.  Either way, I think your patchset needs to
> address the new mount API in some way.  I don't want to speak for
> Christian, but I believe these comments are in keeping with his
> previous comments in this thread.

Thanks for the clarification! It appears we can indeed add coverage
for the new mount APIs without much work.

Attached is a quick draft for this change on top of current patchset.
Is this heading in the right direction?

Thanks,
Song