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

[Paul Moore]

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.

With all that said, you did identify a potential issue with resolving
dev_path multiple times in both AppArmor and TOMOYO.  That does look
like something that we should fix regardless (I see Tetsuo has already
ACK'd your patch, but we are waiting on the AppArmor folks).  However,
what that fix will look like will likely be determined by what you
want to do with respect to both the legacy and new mount APIs.

-- 
paul-moore.com