Technical Committee, which makes final decisions regarding controversial technical issues in the Debian project, approveda change to the systemd package that changes the behavior when working with the /var/lock directory. The systemd system manager since release 258 restricted the ability to write to the /var/lock directory to only root users, while the Debian technical committee approved leaving the old behavior allowing any users to write to /var/lock.
The Debian project rules require preserving the original behavior of applications (settings set in upstream) when creating packages. Making Debian-specific changes to packages outside of project rules requires special permission from the technical committee.
In the case of systemd, the committee supported the proposal not to follow the change that changes the permissions on /var/lock from aim to enhance security, since the ability to publicly write to the /var/lock directory is mentioned in the specification FHS (Filesystem Hierarchy Standard) and is necessary for the continuation of some existing programs. For example, serial applications such as uucp, minicom, mgetty+sendfax and hylafax use the /var/lock directory to separate access to the /dev/ttyS* devices by creating lock files.
The need to restrict access to the /var/lock directory is explained systemd developers protection against DoS attacks. The /var/lock directory is a symbolic link to the /run/lock directory. The partition with the /run directory is usually mounted separately via tmpfs and the possibility of uncontrolled writing to it can be used to overflow the partition and block the creation of new files in the /run hierarchy.
To prevent such attacks from occurring in the presence of unrestricted access, Debian previously used patch, mounting /run/lock in a separate small tmpfs partition. Last year this patch was replaced by the run-lock.mount unit, and this summer this unit removed, after which /run/lock was in /run section In comments to the decision of the technical committee, the former maintainer of systemd recommended not to forget about the noted change and return to a separate mount /run/lock, and in the long term, transfer all applications that rely on /run/lock to lock using the flock mechanism.