Re: [PATCH v2 3/6] landlock: Bump ABI for LANDLOCK_SCOPE_SYSV_MSG_QUEUE
Justin Suess <[email protected]>
| Newsgroups | org.kernel.vger.linux-security-module,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <aohfGjG15BUfOY7X@zenbox> |
On Fri, Aug 21, 2026 at 09:15:31AM -0400, Justin Suess wrote: > On Fri, Aug 21, 2026 at 02:38:15PM +0200, Günther Noack wrote: > > On Mon, Jul 27, 2026 at 07:08:30PM -0400, Justin Suess wrote: > > > Bump the ABI version for Landlock SysV message queue scoping. > > > > > > Signed-off-by: Justin Suess <[email protected]> > > > > The ABI bump is normally put into the same commit as the > > implementation for easier backporting. Otherwise, looks good. > I'll squash them. > > > > Thanks, > > I did wonder about if we need to use the landlock_object here? > > I'm pretty sure SysV message queues stay open after process exit, > which could cause the domain to be pinned by landlock_cred_security, > if programs are lazy and don't close them. > > So it probably needs to be a weak reference. > > But it's unclear what should be the behavior there when the domain > is dropped: > > 1. Should it become inaccessible and belong to *nobody's* domain? > > (i.e when owning domain is dropped, the queue belongs to no domain and is inaccessible to > all LANDLOCK_SCOPE_SYSV_MSG_QUEUE scoped domains) > > 2. Should it be moved to the parent's domain? > > (i.e when owning domain is dropped, the parent domain is the new scope, > and then it's parent, so on and so forth, more complicated, but more correct) > > 3. Or be kept as is. > > (i.e Allow an open sysv message queue to pin a domain > for it's lifetime) > Scratch all of this, I think it's best if the kern_ipc_blob takes a reference to the landlock_hierarchy plus a depth u16. I think this will require introducing a new landlock_put_hierarchy_deferred method because of the runtime context of the ipc hooks, but should be pretty easy. Also refactor domain_is_scoped() to take the server side as (hierarchy, depth). Justin > Either way this almost certainly needs to be rebased since it's been > a little bit and there were significant refactorings of the domain and > ruleset structures since the tracepoints series. > > Justin > > > –Günther