Debian Technical Committee overrides systemd change
Benefits for LWN subscribers The primary benefit from subscribing to LWN is helping to keep us publishing, but, beyond that, subscribers get immediate access to all site content and access to a number of extra site features. Please sign up today!
Debian packagers have a great deal of latitude when it comes to the configuration of the software they package; they may opt, for example, to disable default features in software that they feel are a security hazard. However, packagers are expected to ensure that their packages comply with Debian Policy, regardless of the upstream's preferences. If a packager fails to comply with the policy, the Debian Technical Committee (TC) can step in to override them, which it has done in the case of a recent systemd change that broke several programs that depend on a world-writable /run/lock directory.
The Filesystem Hierarchy Standard (FHS) specifies that the /var/lock directory should be used to store lock files for devices and other resources shared by multiple applications. On Debian, /var/lock is a symbolic link to /run/lock . The /run directory is created as a tmpfs filesystem specifically for run-time files by systemd-tmpfiles during system startup.
Debian Policy still cites the FHS, even though the FHS has gone unmaintained for more than a decade. The specification was not so much finished as abandoned after FHS 3.0 was released—though there is a slow-moving effort to revive and revise the standard as FHS 4.0, it has not yet produced any results. Meanwhile, in the absence of a current standard, systemd has spun off its file-hierarchy documentation to the Linux Userspace API (UAPI) Group as a specification. LWN covered that development in August, related to Fedora's search for an FHS successor.
Locking up /run/lock
The /run/lock directory was deprecated in Systemd v258; rather than dropping the directory entirely, though, the project has changed the default to making /run/lock writable only by root, which is stricter than the permissions Debian had shipped with previously rather than making it world-writable as in the past . The plan is to get rid of /run/lock entirely in the v259 release, though users (or distributions) can still retain the legacy behavior by adding a configuration file in /etc/tmpfiles.d to override systemd's defaults and create the directory with the desired permissions.
The Debian project just released a new stable version, Debian 13 ("trixie"), in August, and work has begun on Debian 14 ("forky"). The current stable version of Debian shipped with systemd v257, so users on stable will not be affected by these changes. But v258 has entered Debian unstable where the change to /run/lock broke other software, such as the Unix-to-Unix Copy program (UUCP) and the cu utility. Use of the directory is not limited to vintage utilities; Zbigniew Jędrzejewski-Szmek objected to removing /var/lock in v259 as it would break alsa-utils and create additional work for distributions:
Doing this would this way just creat a foottrap for distributions: if they notice the change, they'll just create a local override, so we get a more complicated system in total with zero benefit to anyone. If they miss it, things will be broken for a while until users report it. And then they'll add the override.
On August 13, Marco d'Itri—who is listed as a maintainer of the systemd package—filed a bug against the uucp package reporting that systemd v258-rc1-1 had broken uucico , along with filing a bug against the systemd package, which cited the FHS entry for /var/lock . He said that a compromise might be to make the directory writable by the dialout group rather than world-writable. He also mentioned that there was a previous effort in 2014 to modernize software that uses UUCP-style locks to use flock() instead, but it stalled out.
... continue reading