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

[Paul Moore]

On Wed, Sep 30, 2026 at 12:37 PM Song Liu <song at kernel.org> wrote:
> 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?

Can you send out a revised patchset?  I suspect there will be a number
of people who want to review your draft, and it's a lot easier if we
don't all have to apply the patch separately :)

-- 
paul-moore.com