After a little over three months of development, the launch of the new version of systemd 259. This update introduces changes to the system architecture, highlighting the openness to alternative standard libraries, more rigorous privilege management, and stricter technical requirements for future versions.
One of the most talked-about movements in this cycle is the transition towards greater modularity and the elimination of legacy dependencies, paving the way for a Linux ecosystem that is definitively moving away from the standards of past decades.
Main new features of systemd 259
The new systemd version 259 stands out for being the first version to add partial compatibility with Musl, the popular C standard library in lightweight distributions and embedded environments. This integration It is managed through the libc option in the Meson build system. However, because Musl does not implement the NSS (Name Service Switch) functionality, several systemd components remain disabled in this configuration.
Among the anotable absences when compiling with Musl found nss-systemd, nss-resolve, systemd-homed, systemd-userdbd and the DynamicUser parameterFurthermore, it is not possible to run systemd-nspawn without privileges under this library. The developers have warned that maintaining this support in future versions will depend on community demand and the stability of any additional compatibility layers that are developed.
Another new feature of the new version is in the run0 utility, designed as a modern and safe alternative to sudo, which has received the new option –empower. This function It allows you to log in with elevated privileges. without needing to change the user identifier (UID) to root.
Besides that, instead of delegating total control through user switching, –empower uses kernel capability indicators, such as CAP_SYS_ADMIN, to grant the strictly necessary permits to make privileged system calls. In addition, the resulting processes are integrated into a specific group that grants them access to Polkit actions, maintaining a more robust separation of privileges than the traditional sudo model.
The end of an era: Goodbye to System V and new requirements
systemd 259 marks the beginning of the end for compatibility with the System V service scriptsIt has been announced that in the next version, legacy components such as systemd-sysv-generator, systemd-rc-local-generator, and systemd-sysv-install will be permanently removed.
Along with this cleanup of old code, the minimum software requirements for the systemd ecosystem have been significantly raised:
- Linux Kernel: Minimum version 5.10.
- Glibc: 2.34.
- OpenSSL: 3.0.0.
- Util-linux: 2.37.
- Other: Python 3.9.0, cryptsetup 2.4.0 and libseccomp 2.4.0.
Modularity and dynamic loading in libsystemd
Just like part of an initiative to reduce dependencies direct at startup, libsystemd now uses dynamic loading via dlopen() For libraries such as libacl, libblkid, libseccomp, libselinux, and libmount, the system will only load these libraries into memory when their specific functions are required by a process, optimizing resource usage. Additionally, libcap functionality has been integrated directly into libsystemd, simplifying the dependency chain.
El Log handling has changed its default configuration: the journal storage mode (Journal) changes from "automatic" to "persistent", regardless of whether the /var/log/journal directory previously existed.
In the field of networks and virtualization:
- systemd-networkd and systemd-nspawn: Support for NAT rules using iptables is removed, leaving nftables as the only compatible option.
- systemd-resolved: It now allows the use of local hooks (hooks) in /run/systemd/resolve.hook/ to intervene in name resolution requests.
- systemd-importd: Logic for working with TAR files has been integrated natively. Furthermore, both `importd` and `machined` can now be run at the user level, allowing image management in the user's local directory (`~/.local/state/machines/`).
Other innovations
The protocol-based API Varlink received enhancements to allow access to service settings and to make IPC calls such as Reload() and Reexecute(). For system administrators, the inclusion of the OOMKills property in services will be very useful, as it will allow them to track how many times a process was terminated due to lack of memory directly from systemd tools.
Finally, the system boot process becomes more modern with the removal of support for TPM 1.2 in systemd-boot, focusing all security efforts on the TPM 2.0 standard.
If you are interested in knowing more about it, you can consult the details in the following link.