On Wed, Sep 30, 2026 at 12:37 PM Song Liu <[email protected]> wrote: > 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?
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
