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. 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
