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

[Oxana Kharitonova]

Hi Günther!

Apologies for the delayed reply. I took some break. 

Thank you very much for the detailed explanation and for the 
test program.

On 21/08/2026 09:46, Günther Noack wrote:
> Thank you for sending this!
> 
> I have a high level question about this patch set:
> 
> You are adding a check to hook_file_open(), but the existing
> hook_file_open() can already prevent mq_open().
> 
> The following experiment illustrates this:
> * Restrict LANDLOCK_ACCESS_FS_READ_FILE and LANDLOCK_ACCESS_FS_WRITE_FILE
> * Try to run mq_open("/foobar", O_CREAT...)
> 
> Depending on the installed PATH_BENEATH rules, you now see differing behaviour:
> 
> * If we allow READ_FILE and WRITE_FILE on nothing, mq_open() is *DENIED*.
> * If we allow READ_FILE and WRITE_FILE on /, mq_open() is *DENIED*.
> * If we allow READ_FILE and WRITE_FILE on a mounted /dev/mqueue, mq_open() is *ALLOWED*.
> 
> So it seems that the existing file system restrictions are already
> preventing POSIX message queues from being opened?  And not only that
> -- since such Landlock policies are already quite common, it seems
> likely that many existing landlocked programs are already restricting
> opening of POSIX message queues today.

The additional check in hook_file_open() adds a restriction for two sibling domains
created under the same parent. If both siblings share filesystem
access, but must not communicate with each other through POSIX message
queues, the scope check prevents one sibling from opening a queue created
by the other. 

Although I can't say how practical this use case is. I see that it adds 
additional overhead for non-mqeuee files too, but it doesn't seem significant 
as it only checks the inode type and mqueuefs superblock magic.

If you think it's not worth it, I'm happy to remove it.

> So, to clarify:
> 
> * What your patch set is adding is only that we are now additionally
>    taking the Landlock domain scope into account?
> * This distinction only makes a difference for landlocked programs
>    that do not restrict READ_FILE/WRITE_FILE or that do restrict it and
>    then allow-list READ_FILE/WRITE_FILE on a previously mounted
>    /dev/mqueue.
> 
> Maybe this would be interesting to clarify a bit more prominently in
> the cover letter, because it reduces the applicability of this
> patchset?

Agree, I'll add more details in the cover letter. 

> Attached below is a LLM-generated (but double checked) test program
> which you can use to try out the creation of mqueues.  (As first
> argument, use "-", "/" or "/dev/mqueue".)
> 
> 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.
> 
> 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.

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