[PATCH v2 1/9] security: add LSM blob and hooks for namespaces

[Mickaël Salaün]

On Fri, Jul 10, 2026 at 04:42:58PM -0400, Paul Moore wrote:
> On Thu, Jul 9, 2026 at 11:58 AM Mickaël Salaün <mic at digikod.net> wrote:
> > On Thu, Jul 09, 2026 at 09:03:58AM -0400, Paul Moore wrote:
> > > On Thu, Jul 9, 2026 at 5:12 AM Mickaël Salaün <mic at digikod.net> wrote:
> > > > On Wed, Jul 08, 2026 at 11:22:17PM -0400, Paul Moore wrote:
> > > > > On May 27, 2026 =?UTF-8?q?Micka=C3=ABl=20Sala=C3=BCn?= <mic at digikod.net> wrote:
> 
> ...
> 
> > > I'm aware of the new hook guidance, I was the one who documented it :)
> >
> > I know.  I guess that means you're ok with that?
> 
> Yes.

Thanks.  I applied your suggestions wrt comments and patch split for v3.

> 
> Just a heads-up, and some of this depends on timing, but as we've got
> multiple patchsets (there is a SELinux patchset that depends on these
> hooks) I'll want to take this hook additions via the LSM tree.  I can
> take the associated Landlock patches too if you like, or you base the
> Landlock tree off the LSM branch; no worries either way, we can sort
> out the details once the patchset is ready for merging.

If it's all right with you, I'd prefer to carry the LSM hook patches in
the Landlock tree this cycle, so the whole namespace/capability series
stays a single consistent set of commits.  I also have ongoing Landlock
work (e.g. tracepoints) that needs to build on these hooks, which is
easier to manage with them on landlock-next.

That shouldn't hold up the SELinux side: if those patches aren't in a
hurry, letting the hooks stay in the -next branch until the next merge
window also give them some time to get a broader set of checks.  Happy
to revisit if the timing gets tight on your end.