The technical committee responsible for making final decisions on contentious technical issues in the Debian project has approved a change to the systemd package that alters behavior regarding the /var/lock directory. Starting with release 258, the system manager systemd has restricted the ability to write to the /var/lock directory solely to users with root privileges, whereas the Debian technical committee has approved retaining the old behavior, allowing any users to write to /var/lock.
Debian project rules mandate the preservation of the original behavior of applications (settings set upstream) when creating packages. To introduce Debian-specific changes that circumvent project rules, special permission from the technical committee is required.
In the case of systemd, the committee supported the proposal not to follow the change that modifies access rights to /var/lock in order to enhance security, since the ability for public write access to the /var/lock directory is mentioned in the Filesystem Hierarchy Standard (FHS) specification and is necessary for the continued operation of certain existing programs. For instance, applications for operating serial ports, such as uucp, minicom, mgetty+sendfax, and hylafax, use the /var/lock directory to manage access to the /dev/ttyS* devices by creating lock files.
The need to restrict access to the /var/lock directory is explained by the systemd developers as a protection against DoS attacks. The /var/lock directory is a symbolic link to the /run/lock directory. The /run directory is typically mounted separately via tmpfs, and having uncontrolled write access to it could lead to partition overflow and block the creation of new files in the /run hierarchy.
To prevent such attacks when there was unrestricted access, Debian previously used a patch that mounted /run/lock in a separate small tmpfs partition. Last year, this patch was replaced with the run-lock.mount unit, and this summer, this unit was removed, leading to /run/lock being located in the /run partition. In the comments on the decision by the technical committee, the former maintainer of systemd recommended remembering the noted change and returning to separate mounting of /run/lock, and in the long term, migrating all applications tied to /run/lock to use locking via the flock mechanism.
Source: opennet.ru
