Welcome to LWN.net

The following subscription-only content has been made available to you by an LWN subscriber. Thousands of subscribers depend on LWN for the best news from the Linux and free software communities. If you enjoy this article, please consider subscribing to LWN. Thank you for visiting LWN.net!

The systemd v259 release was announced on December 17, just three months after v258. It is a more modest release but still includes a number of important changes such as a new option for the run0 command (an alternative to sudo), ability to mount user home directories from the host in virtual machines, as well as under-the-hood changes with dlopen() for library linking, the ability to compile systemd with musl libc, and more.

Systemd v258 was something of a mammoth release; it took more than ten months to develop and included an unusually large number of new features and changes, which we covered in two installments (part one, part two). When it was released on September 17, Lennart Poettering said the project hoped to speed up its release cycle and push out smaller, more frequent releases—so far, so good.

Empowering run0

With v259 run0 has gained a new feature to retain a user’s UID/GID while taking on the capabilities of root. This feature was implemented by Daan De Meyer, who said that he was inspired to work on it "when I was playing around with bpftrace and systing and got annoyed that the files written by these tools were owned by root instead of my own user".

The feature is invoked with the –empower option. If used, the user can run all privileged operations—and thus any executable on the system—while any files written by processes run by "run0 –empower" will have the UID and GID of the user. One practical benefit of that is that any files created will be owned by the user executing the run0 command, and not root.

As a simple example, running "run0 touch filename" would run touch as root and create filename with root as the owner of the file. Using "run0 –empower touch filename" would run touch as the regular user but with all capabilities, and create filename with the user as the owner of the file rather than root.

Users can also run "run0 –empower" and get a session with root capabilities but retain their UID and GID. The –empower option can be combined with –user to run a command or start a session with the capabilities of the user specified, but retain the UID and GID of the user running run0. Note that if a tool checks for UID rather than capabilities, then –empower will not work.

The other caveat to the –empower feature is that a user’s other processes can interact with the process being managed by run0; De Meyer acknowledges, for example, that a user could attach a debugger to a process started with "run0 –empower", and that the option "gives malicious processes a vector to infiltrate the system". He noted that the same is true of various uses of sudo, too.

Libraries

In the wake of the XZ backdoor in 2024, the systemd project began to explore using dlopen() to load libraries only when required. With v259, the project has changed to use seven libraries with dlopen() instead of shared library linking; now systemd only directly links to systemd’s shared libraries, GCC and GNU C (glibc) libraries, as well as the password-hashing library libxcrypt (libcrypt), OpenSSL (libcrypto), and zlib compression library (libz). Poettering said that the plan is to turn libcrypt and libcrypto into dlopen() dependencies as well in the v260 release.

Note that the project has also added a feature to systemd-analyze to display libraries that are used with dlopen(), since they are not displayed by ldd. The command "systemd-analyze dlopen-metadata filename" will display a table containing all of the libraries accessed via dlopen(), as well as a description of the features that are enabled by the library.

Historically, systemd only worked with the glibc, but there have been requests for systemd to work with the musl libc implementation for some time. With v259, systemd now compiles with musl libc but with a number of limitations. Poettering said that the largest limitation is lack of Name Service Switch (NSS) support, which is used to allow systemd to look up domain names, user names, and group names. Without that feature, he notes, a good chunk of systemd’s infrastructure is gone or half-broken.

One might wonder why the project has bothered with musl libc if it results in a substandard systemd; Poettering said that it was in part to accommodate the postmarketOS project which has adopted musl libc "and now they are stuck with it". A lot of other people have asked for it as well, but he continues to recommend "just use glibc, the pain and limitations musl brings are really not worth it".

Miscellaneous

The systemd-vmspawn command is used to start a virtual machine from an operating system image. With v259 it has a new option, –bind-user; this makes a user’s home directory on the host available in the virtual machine using the virtiofs shared filesystem, and passes the user’s credentials to the virtual machine as well. This makes it possible for a user to log into a virtual machine using the same account information as the host, as long as the targeted virtual machine is running systemd v258 or later. This option was made available in systemd v249 for systemd-nspawn, which is used to run containers.

In addition, there is a new –bind-user-group option that works with –bind-user for systemd-vspawn and systemd-nspawn. As the name suggests, this specifies additional groups (such as wheel) that the user should be added to in the virtual machine or container.

Kernel modules loaded using the systemd-modules-load.service are now done in parallel. While kernel modules are usually auto-loaded, Poettering noted that the service is still popular "for certain commercial offerings", and parallelizing the service will optimize boot times quite a bit. To see how many modules this would impact on a system, run this command:

$ systemd-analyze cat-config modules-load.d

Poettering also suggested that this work may pay dividends in other ways later:

For example, in certain fixed-function usecases it might make sense to load modules via this infrastructure during boot, and then "blow a fuse" for security reasons to disallow any further kmod loading during later boot. Because of that I think this parallelization work has been worthwhile, even though I personally might not be too sympathetic to those commercial offerings I mentioned.

Removals, deprecations, and incompatible changes

With systemd v259, the control group version 2 filesystem (cgroupfs) is mounted with the memory_hugetlb_accounting option, which means that hugetlb memory usage will be counted toward a control group’s overall memory usage. The systemd-networkd network manager and systemd-nspawn utility now only support creating NAT rules with nftables; support for iptables and the libiptc API have been dropped.

Support for TPM 1.2 has been removed from systemd-boot and systemd-stub; TPM 2.0 support is retained. According to the release notes, this may not be much of a loss:

The security value of TPM 1.2 support is questionable in 2025, and because we never supported it in userspace, it was always quite incomplete to the point of uselessness.

System V service scripts have had a good run, but their time is near an end—at least with systemd. The project plans to pull the plug on them in v260, and will be removing several components used to create or work with those scripts.

The project plans to raise the minimum required versions of a number of components with the next release; v260 will require Linux 5.10 or later (with 5.14 or later recommended), and a minimum of Python 3.9.0, libxcrypt 4.4.0, libseccomp 2.40, OpenSSL 3.0.0, util-linux 2.37, and glibc 2.34.

There were 70 issues closed on GitHub for the v259 release, compared with 227 for v258. The milestone tracker shows 84 open issues for v260, and three that are already closed. Most of the issues are bugs and regressions that need addressing. It will be interesting to see what develops during this cycle and if the project keeps to the three-month cadence.

---