Bug#1110980: /var/lock/ is the standard interface for serial devices locks

[Luca Boccassi]

Control: tags -1 wontfix
Control: close -1

On Wed, 13 Aug 2025 10:23:56 +0200 Marco d'Itri <md at linux.it> wrote:
> Package: systemd
> Version: 258~rc2-2
> Severity: critical
> 
> Control: forwarded -1 https://github.com/systemd/systemd/issues/38563
> 
> Breaks unrelated software.
> 
> /var/lock/ is not just the dumping ground for lock files of random 
> applications, but also the published interface for system-wide locks
of 
> serial devices.
> 
> From section 5.9.1 of the FHS:
> 
>    Lock files should be stored within the /var/lock directory
>    structure.
> 
>    Lock files for devices and other resources shared by multiple
>    applications, such as the serial device lock files that were
>    originally found in either /usr/spool/locks or /usr/spool/uucp,
>    must now be stored in /var/lock. The naming convention which
>    must be used is "LCK.." followed by the base name of the
>    device. For example, to lock /dev/ttyS0 the file "LCK..ttyS0"
>    would be created. ^[43]
> 
> I think that this can be easily solved by making /run/lock/ owned by 
> group dialout.

The FHS is dead and severely outdated. As mentioned on
https://github.com/systemd/systemd/issues/38563 support for this will
be removed in 259. Modern utilities should use BSD locks, and IIRC some
serial applications do that already.

A world writable directory in /run/ is a security risk, as it allows
unprivileged processes to DOS the system by exhausting space/inodes,
and then critical services such as udev will stop working (been there,
done that).

If there still remains any packages that need a world writable /run/,
they can ship the tmpfiles.d themselves, and assume responsibility for
it. Anything can ship tmpfiles.d, it doesn't have to be systemd to do
that. I certainly won't try to stop anyone wishing to do it, but also I
do not wish for these old workarounds to ship in this package either.

There's ~2 years time until Forky ships, and that should be plenty time
to either add this workaround elsewhere, or fix remaining programs to
use BSD locks, or both, so I'm not going to hold back the new version
from testing for this niche case, sorry.