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.