sh/init.sh.Linux.in: remove uucp group from /run/lock

[sertonix]

I am not aware of a reason why the uucp group should have r/w access to /run/lock. Also the current configuration allows the uucp group to delete and replace entries owned by other users/groups from /run/lock which could be dangerous.

Ref https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/69933

[navi-desu]

looking over the git history, mounting /run was introduced in 64ef51a, already chowning /run/lock to root:uucp since the beginning, and no explanation of why

i'll try to dig a bit but if i can't find anything, this seems good to merge

[navi-desu]

it seems to be because /var/run/lock is (was?) used by uucp directly: https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch05s09.html

[sertonix]

It seems that debian tries (or tried) to move to flock instead of the lock files: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=734086, https://stackoverflow.com/questions/30316722/what-is-the-best-practice-for-locking-serial-ports-and-other-devices-in-linux

[ncopa]

seems like at least minicom needs this for its support for "UUCP-style lock files on serial devices". https://linux.die.net/man/1/minicom

[sertonix]

minicom will automatically use flock when uucp style doesn't work: https://salsa.debian.org/minicom-team/minicom/-/blob/master/src/updown.c#L482

We may need to fix minicom to work when one instance uses uucp-style and another one uses flock. This is already an issue though.

[ncopa]

So this should be fixed in minicom rather than to set group ownership to uucp?

[navi-desu]

i'm sorry for taking so long to come back to this.

by what i understood, some (mostly old) software expects to be able to write tty lockfiles to /run/lock, ideally they all should move to using bsd-style locks

so i'd like to eventually remove /run/lock, but until programs don't need it anymore, i'd rather keep an option for distros to opt for a group in /run/lock

so i propose #919 moving that build-time configuration, so distros wishing to remove uucp can -Duucp_group=root. we could even make it a rc.conf option having the buildtime value as the fallback (so users could choose to add back a lock group) if that's desired

[sertonix]

I guess that makes sense.

[sertonix]

For the record, I have found one mention of /run/lock permissions: https://gitlab.freedesktop.org/FHS/fhs-spec/-/issues/26

[navi-desu]

For the record, I have found one mention of /run/lock permissions: https://gitlab.freedesktop.org/FHS/fhs-spec/-/issues/26

i'm unsure how much this will matter since systemd itself is phasing out /var/lock and uucp by default (by removing the tmpfiles config for it)

modern programs are supposed to use bsd locks in the serial nodes directly, the concern here is only legacy tools by what i can tell