#1110981 should not use /run/lock/ for private lock files

Package:
uucp
Source:
uucp
Description:
Unix to Unix Copy Program
Submitter:
Marco d'Itri
Date:
2025-08-25 12:11:02 UTC
Severity:
normal
#1110981#5
Date:
2025-08-13 08:41:23 UTC
From:
To:
systemd 258~rc1-1 changed the permission of /run/lock/ to not be
world-writeable, and this broke uucico:

uucico bofh - (2025-08-13 10:05:38.23 10405) ERROR: creat (/var/lock/TMP00000028a5): Permission denied

Part of the problem here is that UUCP uses /var/lock/ both for "private"
locks, which should be moved elsewere (e.g. a tmpfile fragment could
create /var/lock/uucp/ with the correct permission), and for serial
device locks, which are a standard API documented in the FHS.

I have opened #1110980 on the systemd package about the second issue.

#1110981#10
Date:
2025-08-25 12:09:32 UTC
From:
To:
I can confirm this bug.  It has caused significant communication breakdown as suddenly
all my outbound mails were no longer transported due to the lack of permission to create
the lock file.

Changing the group of /run/lock to "uucp" and adding g+w permissions works as a work-around,
but given that /run/lock is RAM only, this is non-persistent and needs to happen after every boot.