Hi Paul, On Tue, Sep 29, 2026 at 8:41 AM Paul Moore <[email protected]> wrote: > > On Tue, Sep 29, 2026 at 2:21 AM Song Liu <[email protected]> wrote: > > On Mon, Sep 28, 2026 at 3:35 PM Paul Moore <[email protected]> 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@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
0006-vfs-Call-mount-LSM-hooks-from-the-new-mount-API.patch
Description: Binary data
