Highlights from systemd v258: part two

Systemd v258 was released on September 17 after more than nine months of development. LWN has already covered some of the features and changes being readied for v258 before it was final. Now that the release is out, it is time to look at more of what came in v258, including a sandbox shell, new boot options, service-level disk quotas, and enhancements to systemd-resolved.

Sandbox shell

Systemd provides several ways to put services into a sandbox to improve system security by removing or restricting access to various functionality. For example, one might set the ProtectSystem=full directive in a service file to set the /boot, /etc, and /usr directories as read-only for a service. The project recommends turning on as many sandboxing options as possible.

To get a sense of what is already sandboxed, systemd has the "systemd-analyze security" command to provide an overview of the sandboxing settings for all service units. The command can also display a full list of settings for a service, their status, and the overall "exposure" level:

    # systemd-analyze security servicename

Inspecting a service's sandbox options is helpful, but it may not be enough if a sandboxed service is failing or misbehaving, as Lennart Poettering points out, "since it's the daemon you sandbox, and your admin tools are outside of that sandbox, it's sometimes challenging to analyze how the daemon sees things".

In v258, the project has added the unit-shell option to systemd-analyze; this opens a shell inside a running service's sandbox. For instance, this command would open a shell with the same environment as the NetworkManager service.

    # systemd-analyze unit-shell NetworkManager.service

Currently this is only available for running services, but Chizoba Odinaka, who developed unit-shell as an Outreachy Google Summer of Code project, said that there will be another option added for non-running services in the future.

New boot options

A few new Type #1 Boot Loader Entry Key options have been added to the systemd-boot UEFI boot manager. Type #1 entries are text-based configurations that are suitable for a number of image types, while Type #2 entries are single-file EFI images that combine a kernel with its configuration, initrd, and other components.

Now systemd-boot supports Type #1 entries for Unified Kernel Images (UKI) located on disk (with the uki option) or images located on a remote server (uki-url). If a system is booted from a network-boot-provided UKI, systemd-stub will write its URL to the LoaderDeviceURL EFI variable, which can be used to look for a root disk image or other resources at the same location. This opens up the ability to boot from a rootfs downloaded over HTTP.

Note that this is HTTP only, not HTTPS. In a discussion about the feature on GitHub, Poettering said that it should not matter if artifacts are "attacked on the wire" because they would be validated using Secure Boot and TPM measurements. He also questioned whether the UEFI certificate database could be kept reasonably up-to-date in order to use HTTPS, unless an organization is enrolling its own certificates in the allowed certificate database.

There is also a new reboot-on-error setting in the systemd-boot configuration file, loader.conf. This allows users to specify whether to reboot or show the EFI menu again in case the system fails to start when using a boot entry. The default is to reboot if boot counting is enabled and the "tries left" counter is greater than zero. This default helps to avoid putting the system into an eternal reboot loop.

Service-level disk quotas

Systemd has long allowed users to control where services store cache, logs, or state information via the per-unit CacheDirectory=, LogsDirectory=, and StateDirectory= settings. These options not only provide control of where services put data, they also makes it simple to query systemd to find out where data is kept for a service, and to clean up afterward by using "systemctl clean servicename" if a service is removed from a system.

With v258, users can also set service-level disk quotas using per-service settings. For example, to set a disk quota for a service's logs, one would use LogsDirectoryAccounting= and LogsDirectoryQuota=. Currently quotas are only supported on ext4 and XFS filesystems; Btrfs is not supported. Poettering said that this is because "quota works completely differently on btrfs", making it more difficult to implement. He said that it is possible that Btrfs support will be added in the future, however.

Miscellaneous

Muhammad Nuzaihan Bin Kamal Luddin submitted a patch in August 2024, for systemd-resolved; he wanted to be able to explicitly enable or disable queries for IPv6 AAAA records, because of problems when trying to resolve A and AAAA records for the same domain name. Poettering felt that was too specific and asked for the feature to be expanded to a RefuseRecordTypes= option that would allow specifying any resource record (RR) types.

After quite a bit of back-and-forth discussion and work to implement and test the feature, systemd-resolved now has the ability to block any type of RR lookup, which allows users to set other policies such as disallowing ActiveDirectory lookups. In addition, systemd-resolved now has a feature for parallel A and AAAA lookups; if a request for a domain name resolves quickly for either the A or AAAA record, then it will shorten the timeout for the other record. The release notes indicate this is aimed at improving performance when a server responds quickly to the A request but slowly or not at all to the AAAA request.

There are many cases when systemd needs to ask the user for a password, such as at boot time when it needs the password to unlock an encrypted disk. Historically, this is done using password agents that are invoked by placing an INI-like file in /run/systemd/ask-password, which was not as simple as using a standard API. Systemd did not have a D-Bus API for this because D-Bus is not available during the early part of a boot sequence, which made it unsuitable for something like getting a disk-encryption password. With v258, systemd has added a varlink API (io.systemd.AskPassword.Ask) that can be used instead of the INI files, so a service can just use an IPC call to get a password instead.

Onward to v259

On September 17, Poettering celebrated getting v258 out the door; he hoped to move to smaller and more frequent releases in the future. Two of the features that look likely to wind up in v259 include Wayland keyboard configuration support in systemd-localed, and a systemd-boot feature that would allow it to natively update system firmware using UEFI capsules.

There are far fewer issues assigned to the milestone tracker for v259 than there were for v258; currently there are 16 tickets that have been closed and 80 that remain open for v259, whereas there were 228 issues closed by the time v258 was released. Of course, it's possible that more work will be added to the board as this release cycle continues.