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.

clone 1110980 -1
severity -1 normal
retitle -1 Change the policy for locking serial devices?
reassign -1 debian-policy
thanks

systemd upstream wants /var/lock/ to not be world-writeable for very
good reasons, but FHS, which is referenced by Debian policy, still
mandates it as the ABI for the lock files of serial devices.
I am opening this bug to explore our options.

For the time being, a good enough compromise for Debian is to have
/var/lock/ writeable only by group dialout.
But HDB-style serial device locks come from the early '80s, and maybe at
this point we can agree that just using flock(2) on the serial device is
a better design.
Indeed, 12 years ago there was an attempt to stop using HDB-style locks
(see #728023), but it did not lead to a policy change and it was
obviously not completed since there are still many packages using them.

OTOH a transition would not be totally trivial, because some software
would need to be patched by their maintainers to implement flock(2)
locking.