Re: [PATCH 0/6] landlock: Add POSIX message queue scoping

[Oxana Kharitonova <webprosto@gmail.com>]

Hi Günther!

As promissed, I'm following up with a more complete answer.  

On 14/09/2026 15:10, Oxana Kharitonova wrote:
> On 21/08/2026 09:46, Günther Noack wrote:
>> What *might* still be interesting to restrict though: While mq_open()
>> checks the READ_FILE and WRITE_FILE rights, it checks none of the
>> LANDLOCK_ACCESS_FS_MAKE_* rights -- the message queue gets still
>> created, even when the mq_open() is denied and returns with an error.

I revisited my changes and noticed the gap you mentioned regarding
mqueue creation. Thanks for highlighting it. I'll address it in v2.

>> To expand on Justin's comment in [1] -- it feels that there are maybe
>> still some gaps in the "lifecycle management" of these message queues
>> that might be worth thinking systematically about, because both
>> mq_unlink() and the creation of the message queue entries are
>> currently apparently not restrictable yet?  It makes me wonder whether
>> hijacking of message queue names (creating same-named queues in other
>> Landlock domains) is a problem then?  Do you have thoughts on this?
> 
> I need to think about it more and check how the mq_unlink works, taking
> into account the comment from Justin and Mickaël.
> I'll follow up with a more complete answer.

Regarding the lifecycle management of POSIX message queues, I haven’t
found a good solution yet. I experimented with test programs, but the
main constraints come from the POSIX message-queue semantics. A queue is
independent of its creator’s lifetime and remains until mq_unlink() is
called explicitly and all open descriptors are closed. Its name must be
unique within the IPC namespace, but the same name can be reused after
the existing queue has been unlinked.

If mq_unlink() is restricted for a process, a stale queue could remain
and that process might be unable to clean it up. This seems to be the
concern Mickaël raised in [2]. However, Landlock restrictions apply to
the restricted process or domain, rather than globally to the queue, so
another process might still be able to access or unlink it if its
permissions allow. Therefore, I don’t currently see how to restrict this
correctly through a Landlock policy, other than documenting the
limitation. Let me know if you have other thoughts or I'm missing
something.

>>
>> Thanks,
>> –Günther
>>
>> [1] https://lore.kernel.org/all/amKDYoOSvHMzVbKX@suesslenovo/

Thanks,
Oxana

[2] https://lore.kernel.org/all/20260728.Heephie1tai3@digikod.net/