Landlock Scoped Signal Control
When a thread is in a signal-scoped Landlock domain, signal sending is only allowed if:
- the recipient Landlock domain is the same or a child domain of the sender Landlock domain, or
- if the sender and recipient thread are both part of the same process.
An overview of Linux signals is in signal(7).
The common case: Signal sending with kill(2)
Normally, signals are sent using the kill(2) system call.
Less common cases
In some weird cases, signals are also sent to processes indirectly through other interactions, and for some of these, it is worth asking who the sender thread is.
SIGIO case
The SIGIO mechanism is a spiritual predecessor of
select(2),
poll(2) and
epoll(7).
The
SIGIOmechanism has serious drawbacks:
- In the signal handler, it is unclear which file descriptor caused the signal.
- Loose definition of what constitutes a signal-worthy event.
If you are looking for a mechanism to get notified on data availability, you should look into the other mechanisms instead.
A process can register a signal to happen whenever a given file descriptor has an event (e.g. data ready for reading). This is set up using:
fcntl(fd, F_SETSIG, SIGIO); /* decide the signal; default: SIGIO */
fcntl(fd, F_SETOWN, getpid()); /* decide who gets the signal */
fcntl(fd, F_SETFL, O_ASYNC); /* turn on signaling */
As additional quirks,
- It can also be made to send different signals using
F_SETSIG. - It can be made to signal an entire process group by passing a negative PGID value to
F_SETOWN.
The canonical documentation for the SIGIO mechanism is in
F_SETOWN(2const).
In Landlock’s context, the thread which called F_SETOWN is the sender of the signal
for the purpose of the Landlock policy enforcement, i.e. when the caller of fcntl(F_SETOWN) could be sending a signal with kill() to the same target, the signal will get delivered.
In particular, the process which made new file descriptor data available (e.g. by writing into a pipe) is completely irrelevant for this check.