Günther's Wiki

Advanced Programming In The Unix Environment

Sun, 11 Oct 2026 19:00:03 +0000

http://www.apuebook.com/

https://www.amazon.com/Advanced-Programming-UNIX-Environment-3rd/dp/0321637739

I cannot recommend this book enough.

Controlling Terminal Acquisition

Sun, 11 Oct 2026 18:17:10 +0000

On Linux, a daemon that accidentally opens a terminal device can accidentally make that terminal its controlling terminal.

Controlling terminals have a lot of power. Specifically, they can send signals to that daemon going forward and also interrupt the processes’ execution. If an attacker can predict and write one of the file paths opened by a daemon, if that daemon does not pass the special O_NOCTTY flag, then they can create a pseudoterminal that they control and possibly make the daemon attach to it, putting themselves in the position of sending signals to that daemon.

This is described in more detail in daemon(7), where it is listed as the last item to look for when implementing a daemon:

As new-style daemons are invoked without a controlling TTY (but as their own session leaders) care should be taken to always specify O_NOCTTY on open(2) calls that possibly reference a TTY device node, so that no controlling TTY is accidentally acquired.

What is the portable way to purposefully acquire a controlling terminal?

First open(2) the terminal device, then call the TIOCSCTTY IOCTL to make it the controlling terminal.

This is a (correct) snippet from the foot terminal source code, file slave.c:

pts = open(pts_name, O_RDWR);
if (pts == -1) {
    LOG_ERRNO("failed to open pseudo terminal slave device");
    goto err;
}

if (ioctl(pts, TIOCSCTTY, 0) < 0) {
    LOG_ERRNO("failed to configure controlling terminal");
    goto err;
}

What happens on other Operating Systems?

Other UNIX-like operating systems have largely addressed the issue – open(2) does not implicitly attach to a controlling terminal any more, and attachment must be done explicitly with the IOCTL.

💡 Software which has been ported to run on the BSDs is already doing it correctly.

The BSDs require the IOCTL for attachment

According to AdvancedProgrammingInTheUnixEnvironment (3rd edition), section 9.6, the split was initially between BSD-based systems (which only attach with the IOCTL) and System V-based systems (which attach implicitly on open(2)).

For the three main BSD derivatives, the man page termios(4) (FreeBSD, OpenBSD, NetBSD) has the same wording:

A controlling terminal is never acquired by merely opening a terminal device file.

Mac OS attaches implicitly on open(2)

According to AdvancedProgrammingInTheUnixEnvironment, on Mac OS, an open(2) on a terminal does the attachment implicitly.

Interesting resources

Debian codesearch for TIOCSCTTY

Landlock Listen Control

Tue, 01 Sep 2026 19:51:36 +0000

🐞 Bug (for TCP)

Landlock Sctp Port Control

Tue, 01 Sep 2026 19:50:14 +0000

🐞 Bug

Big Landlock Networking Fix

Tue, 01 Sep 2026 19:36:17 +0000

Landlock’s current features for restricting networking are limited as of today (September 2026).

In my understanding, the missing pieces are:

The way to think about this is by considering the state graph for socket connections on connection-oriented protocols. Operations that we should restrict are highlighted in red:

Notes:

This diagram omits bind(2), because both listen(2) and connect(2) work also without it.
For connection-less protocols, the states are somewhat different, see LandlockUdpPortControl.

1. Make it impossible to contruct sockets of certain types

Control socket(2): Restrict creating sockets, filtered by family, type and protocol arguments: LandlockSocketTypeControl

As I discussed on my weblog before, you can absolutely create listening sockets without calling bind(2). It is listen(2), not bind(2), which starts to listen on a port, and it hands out an emphemeral port if needed.

2. Control operations through which you can create connections

For socket types that are common, we may have cases where we want to permit their creation and use, but restrict the ways in which incoming and outgoing interactions can be done.

2.1. More protocol support

Control bind(2) and connect(2) for these additional connection-oriented protocols:

Multipath-TCP: LandlockMptcpPortControl
SCTP: LandlockSctpPortControl
SMC: ?

Compare with Landlock erratum 1: In the initial version of the LandlockTcpPortControl, these additional protocols were accidentally restricted as they also use sockets of family AF_INET/AF_INET6 and type SOCK_STREAM.

Related Landlock controls which already exist:

LandlockTcpPortControl (connection-oriented)
LandlockUdpPortControl (connection-less)
LandlockUnixConnectControl and LANDLOCK_ACCESS_FS_MAKE_SOCK (connection-oriented)

2.2. Control listen(2)

Additionally:

Control listen(2) for all of the protocols where we restrict connect(2) as well: LandlockListenControl

Landlock Mptcp Port Control

Tue, 01 Sep 2026 18:16:39 +0000

📧 Patch 🐞 Bug

A part of the BigLandlockNetworkingFix.

It’s like LandlockTcpPortControl, but for Multipath-TCP.

Since MPTCP is backwards compatible with regular TCP, restricting MPTCP in one way or another is needed to effectively restrict the creation of incoming and outgoing TCP connections.

Landlock Udp Port Control

Fri, 21 Aug 2026 09:02:39 +0000

in Linux 7.2

Adds LANDLOCK_ACCESS_NET_BIND_UDP and LANDLOCK_ACCESS_NET_CONNECT_SEND_UDP.

TODO: Merge this page with LandlockTcpPortControl?

Landlock can restrict the use of connect(2) and bind(2) with UDP ports.

API

In struct landlock_ruleset_attr, in the field:

__u64 handled_access_net;

you can now set:

LANDLOCK_ACCESS_NET_BIND_UDP: Bind a UDP socket to a local port.
LANDLOCK_ACCESS_NET_CONNECT_SEND_UDP: Connect or send via a UDP socket.

Documentation commit

Landlock Posix Message Queue Control

Fri, 21 Aug 2026 07:13:38 +0000

Review Thread | 🐞 Bug

Review notes:

API for POSIX message queues: mq_open(), mq_close(), mq_unlink() etc.
Under the hood,
- IPC namespace holds a reference to the mqueuefs
- Operates on files in that file system as a registration mechanism
mqueuefs can be mounted on /dev/mqueue using:
```
mount -t mqueue none /dev/mqueue
```

Maybe surprisingly, LANDLOCK_ACCESS_FS_READ_FILE and LANDLOCK_ACCESS_FS_WRITE_FILE already restrict the opening of mqueuefs files, and that extends to opens happening through mq_open(2)!

Landlock Tracepoints

Fri, 21 Aug 2026 07:13:17 +0000

📧 Review Thread | 🐞 Bug

TODO

Landlock Namespace And Capability Control

Fri, 21 Aug 2026 07:12:18 +0000

Review: https://lore.kernel.org/all/20260726161400.3010511-1-mic@digikod.net/ (Pending)

Landlock System Five Message Queue Control

Fri, 21 Aug 2026 07:10:43 +0000

📧 Review thread | 🐞 Bug

Idea: LANDLOCK_SCOPE_SYSV_MSG_QUEUE as a scoped bit restricts the use of SystemV message queues

Notes on the SystemV message queue mechanism

msqid live in a IPC-namespace-wide registry and can be used by any process if the file-like permission bits allow it based on UID and GID
- A msqid is not a file descriptor - any process guessing the right msqid can try to use it
💡 SystemV message queues have a key squatting problem:
- Before the queue is created, another process can create a queue with the same key by predicting the key and creating it. Many programs with fall for it and use that queue, because they create the queue on demand and don’t check properly who owns it.
- Without Landlock, if process permissions are determined purely based on UID and GID, processes can protect against key squatting by using msgctl() with IPC_STAT and checking the CUID and CGID in struct ipc_perm (creator UID and GID)
- Both the key and the msqid can be predicted:
  - Keys are often static. ftok(3) returns a key that might be guessable as well.
  - Msqids can be listed with a msgctl(2) call or from proc, as implemented in the ipcs tool.

Overview

Free Bsd Capsicum

Fri, 05 Jun 2026 13:17:30 +0000

Landlock Scoped Signal Control

Fri, 05 Jun 2026 09:49:30 +0000

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 SIGIO mechanism 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.

Ukulele Web Syndication

Tue, 17 Mar 2026 21:24:11 +0000

An RSS file (ReallySimpleSyndication) for UkuleleWeb can be generated with the uku rss tool.

An example invocation is:

uku rss -wiki.title="My wiki" -wiki.base_url=https://wiki.gnoack.org/ wikidir/*

The output of the tool is the RSS file.

You can invoke this in a cron job on your webserver and make it available as a static file.

Controlling included pages

You can control the included pages using either of:

Passing a different list of pages on the command line
Passing a -suppress flag (a marker in markdown files that indicates pages to exclude)

Other flags

Flag	Meaning
`-feed.max_items`	Maximum number of feed items
`-feed.suppress`	If set, suppress pages whose markdown contains this string
`-wiki.base_url`	base URL, e.g. `https://wiki.gnoack.org/` (required)
`-wiki.title`	site name (required)
`-wiki.description`	longer site description

Landlock Domain Is Scoped

Sat, 14 Mar 2026 23:05:43 +0000

The domain_is_scoped() helper implements the following predicate:

$\forall_{l \in [0, 16)} (hasbit (self, l) ⟹ D (self, l) = D (other, l))$

That is, we require for each layer l nesting depth that:

If scoping is active at the layer,
Then the domains of self and other are the same at the given nesting depth.

For example:

Landlock Tcp Port Control

Tue, 10 Feb 2026 23:35:18 +0000

Landlock can restrict the use of connect(2) and bind(2) with TCP ports.

⚠️ Known issues

Multipath-TCP is not covered

By creating a Multipath-TCP socket, server processes can side-step the bind(2) restriction and still expose a socket which single-path TCP clients can connect to. (🐞 https://github.com/landlock-lsm/linux/issues/54)

See LandlockMptcpPortControl

listen(2) without bind(2) also works

You can listen also without doing a bind(2) first. (The kernel will assign an ephemeral port.)

API

struct landlock_ruleset_attr is extended by the new field:

__u64 handled_access_net;

with the possible access rights:

LANDLOCK_ACCESS_NET_BIND_TCP: Bind a TCP socket to a local port.
LANDLOCK_ACCESS_NET_CONNECT_TCP: Connect an active TCP socket to a remote port.

When these are passed during ruleset creation, the use of bind(2) and connect(2) for TCP sockets will be forbidden by default when the ruleset is enforced.

To add an exception for a specific TCP port, fill the struct landlock_net_port_attr:

struct landlock_net_port_attr {
        __u64 allowed_access;
        __u64 port;
};

and add it as an exception to the ruleset using landlock_add_rule(2).

landlock_add_rule(ruleset_fd, LANDLOCK_RULE_NET_PORT, &attr, 0);

Example

This is partially discussed in the LandlockTcpServerExample.

Landlock Unix Connect Control

Tue, 10 Feb 2026 22:22:50 +0000

✅ in Linux 7.1

🐞 bug #36 💾 github 📬 old hook patch 💾 V1 V2 V3 V4 V5 V6 V7 V8

💡 TL;DR: A Landlock control for restricting the connect(2) operation on UnixDomainSockets.

Server-side can already be restricted through LANDLOCK_ACCESS_FS_MAKE_SOCK, a filesystem access right which is required to create the socket file.

Overall TODOs

Review from AppArmor folks for hook is still missing (blocked on AppArmor)
- Georgia Garcia has replied 📧
- John Johansen (still pending)

Work in Progress on 💾 github

V8 (tag `unix-connect-v8`)

for nicety, revise the order of
use the current month as reference point when updating the documentation date
fix the m68k GCC 15 bug (hopefully)

V7 (tag `unix-connect-v7`)

Collected TODOs from V6 review:

1/9: Hook needs another revision based on Paul’s (revised) feedback and on Mickaël’s feedback (➡️ Justin)
2/9: Capitalize subject line
3/9: What guarantees that the dom_other stays valid after unix_state_unlock? (Maybe just keep it a bit longer)
3/9: Various comments (📧)
- commit msg: explain the u16 access_mask_t to u32 change
- Open question: What is BUILD_BUG_ON() good for in domain_is_scoped()? (Partially postponed for V8, because it’s somewhat of an independent concern)
5/9: Subject line (selftests/landlock)
6/9: Rename access_fs_16 (in a separate commit)
7/9: Commit message typos
9/9: Commit message lacks description
9/9: We are missing to handle case 6 in a switch statement?
all: Run check-linux.sh.
- It flags that we should use BIT(n) instead of 1 << n, but that does not exist in tests.
- It complains about the Documentation date in the main patch set, but that feels like a very minor update.

V6

Collect TODOs from 📧 V5 review once the discussion has settled:

selftests: check path length when populating sun_path
Docs: squash design decisions update into the main implementation commit and cross-reference it
LSM hook: Move LSM hook call below socket type check (V6)
LSM hook: Mention that hook gets called without any locks held
Impl: Unify domain_is_scoped with unmask_scoped_access? (📧)
- Decision: Better to not unify
PENDING: Some open questions about unmask_scoped_access() logic (📧)
Impl: Locking and SOCK_DEAD (📧)
- Decision: Check SOCK_DEAD and lock using unix_state_lock()
https://lore.kernel.org/all/20260218.ohth8theu8Yi@digikod.net/ (set EUID for coredump test)
https://lore.kernel.org/all/20260218.AXoosuwo8aen@digikod.net/ (Inline code in docs)
https://lore.kernel.org/all/20260308.zie6thaiP0aj@digikod.net/

Then:

Fix up cover letter and send

Appropriate locking for accessing `other`’s creds

Do we have to double check that the socket is not dead (c.f. sock_orphan())?
Locking maybe comparable to sk_user_ns (code, refs)?

V5 (sent)

Fix up cover letter
test that coredump sockets stay unaffected (📧)
follow Tingmao’s approach to test the scope (📧)
- Tingmao’s patch set: https://lore.kernel.org/all/cover.1767115163.git.m@maowtm.org/
- Use Tahera’s scoped_base_variants.h
- Does that mean that we can remove the old test? – YES
Simplify fs_test.c
Add missing audit test to fs_test.c.

Notes

Before sending out patches, remember to run the checks:

just landlock-check-linux
git rebase -i --exec "just landlock-check-linux" mic-next

Sending a new patch version:

git format-patch --cover-letter -v8 --range-diff=unix-connect-v7 base-commit
just send-email v8-*.patch  # accumulate recipient lists in the configuration

Landlock Unix Domain Socket Connect Control

Tue, 10 Feb 2026 22:19:24 +0000

See LandlockUnixConnectControl

Pocketbook Edu Id Crash

Sun, 25 Jan 2026 12:16:22 +0000

After the latest software upgrade on my Pocketbook Inkpad Color 3, I can not log in to my library through Switch edu-ID any more. Posted on the Wiki for reference, in case other people run into the same. I reported the bug to both Pocketbook and Switch (2026-01-25).

I got an answer from Pocketbook (2026-01-26) confirming that the built-in browser is known to crash after the last software update on the edu-ID page, and that they are working on a solution. There is currently no workaround available.

You can check for updates at https://pocketbook.ch/en-ch/support?model=2256 - firmware should be newer than U743k3.6.10.2854

Summary and impact

Apps crash when displaying the “Switch edu-ID” log in form for library login (https://eduid.ch). This log in system is used across a broad network of Swiss universities and libraries.

The crash happens from all apps: the Onleihe app, the Libby app and the Browser app itself (see the two reproductions below).

System configuration

Software version: U743k3.6.10.2854 (2026-01-05)
Localization: WW
Country: Switzerland

Reproduction (Onleihe app)

The app crashes before you can enter your username. (Reproduction is possible without having an account.)

Steps to reproduce:

Open Onleihe app
Find Library
Pick “Zürich (Zentralbibliothek Zürich)” (e-Thek website opens inline)
Pick “Zentralbibliothek Zürich” in library selection form (embedded browser redirects to the switch edu ID log in form)

Observed result:

The edu ID log in website starts rendering and shows the logo, but then the Onleihe app crashes before it is fully displayed.

Expected result:

Reproduction (Browser app)

Navigate to https://eduid.ch/
In menu, pick “Sign in” (Links to login.eduid.ch)

Result:

Fosdem Twenty Six

Mon, 12 Jan 2026 19:24:50 +0000

FOSDEM 2026 - It is happening

🌍 Website

⏰ Schedule

✊ ~~Railway Union accounces strike Jan 26-30~~

📽️ Tentative Video Recordings

Talks

Mickaël Salaün: Island: Sandboxing tool powered by Landlock
Daniel Stenberg: Open Source Security in spite of AI