/run and /run/lock permissions

dimich · 2020-12-17 13:11:21

Shouldn't /run and /run/lock directories have "rwxt" permissions by default? Some applications try to create lock files there, e.g. applications which work with serial port. Even if user is in uucp group and has access to /dev/ttyS*, applications fail because can't create lock file.

V1del · 2020-12-17 13:57:23

The run directory and it's relevant permissions are populated via systemd-tmpfiles

This reads like a XY problem.

What's your actual issue, which exact program do you have which exact issue with?

Last edited by V1del (2020-12-17 14:00:04)

WorMzy · 2020-12-17 14:01:38

dimich wrote:

Shouldn't /run and /run/lock directories have "rwxt" permissions by default?

No. See https://wiki.archlinux.org/index.php/Sy … rary_files and `man 5 tmpfiles.d`

dimich · 2020-12-17 14:42:42

V1del wrote:

What's your actual issue, which exact program do you have which exact issue with?

For example, ckermit. It has hardcoded lock path as "/var/lock" which is symlinked to "/run/lock". This path can be overrided with LOCK_DIR environment variable, and all users in a system must have this variable set to the same value.
The question is more theoretical. As lock files in /run/lock represent aqurance of some resources, and process can aquire a resource, it should be able to indicate resource is in use.

zener · 2024-12-15 06:34:43

I wanted to use ckermit and just ran into this problem in 2024.
I also observe that on Gentoo /var/lock is owned by uucp. Is this common among other Linux distributions?

seth · 2024-12-15 08:40:33

Seems like a ckernit specific issue - and probably hack-a-round
https://en.wikipedia.org/wiki/UUCP
https://en.wikipedia.org/wiki/Kermit_(protocol)

Why should uucp be special itr? ALSA and dmraid use that path and aren't uucp related.
Allowing unprivileged processes to muck around w/ locks of privileged processes and essentially forcing those to immute their locks to please some special-needs process is hardly a viable approach => fix ckermit.

Resp. work around it.
Add a tmpfile /run/lock/uucp w/ appropriate ownership and default the lock there - seems we're patching ckermit downstream anyway.

dimich · 2025-01-05 16:33:21

seth wrote:

Add a tmpfile /run/lock/uucp w/ appropriate ownership and default the lock there - seems we're patching ckermit downstream anyway.

This patch doesn't seem to make much sense. Locks are not to prevent running second instance of the same program but to prevent communication interference from other programs. To ensure this, all programs that use tty must follow the same rules.

There is a mess with locking in general.

picocom locks directly /dev/ttyX (build option), as adviced by Serial-HOWTO a decade and half ago.
minicom tries to lock /var/run/LCK..ttyX and silently ignores the error.
ckermit tries to lock /var/lock/LCK..ttyX as per Filesystem Hierarchy Standard but fails.

seth · 2025-01-06 12:18:15

Eewww.
So ckermit, minicom etc would need elevated privileges to write the lock.

There's however https://man.archlinux.org/man/extra/min … FIGURATION

Serial port setup
…
B - Lock file location
On most systems This should be /usr/spool/uucp. GNU/Linux systems use /var/lock. If this directory does not exist, minicom will not attempt to use lockfiles.

https://man.archlinux.org/man/extra/pic … .en#nolock actually defaults to /var/lock/LCK..ttyS0 and only falls back to flock?

Either way, unprivileged processes wriing around in /run/lock (var/lock) could be granted w/ 1777 (sticky bit protects restricted files, like /tmp)
Edit: /usr/lib/tmpfiles.d/legacy.conf - post your systemd bug but give me a moment to get some popcorn

Last edited by seth (2025-01-06 12:21:07)

dimich · 2025-01-06 20:07:48

seth wrote:

B - Lock file location

That's what I'm talking about: to make it work properly, every program should be configured individually, but in agreement with others.

seth wrote:

https://man.archlinux.org/man/extra/pic … .en#nolock actually defaults to /var/lock/LCK..ttyS0 and only falls back to flock?

In picocom UUCP-style lock is disabled by default and flock is enabled. PKGBUILD doesn't change defaults.
With --nolock it doesn't try to lock anything, as expected.

seth wrote:

Either way, unprivileged processes wriing around in /run/lock (var/lock) could be granted w/ 1777 (sticky bit protects restricted files, like /tmp)

It could, as suggested in my initial post. However, it introduces another potential issue: malicious user can create lock file even without opening corresponding tty and provoke denial of service for legitime user program¹. Looks like a fundamental drawback in FHS, in conjunction with that fact that serial ports are hard-wired to ttys in kernel, and ttys must allow multiple access.

flock(2) on /dev/ttyX seems to be the most proper solution. But it doesn't seem to be cross-platform and only few programs implement it.

seth wrote:

Edit: /usr/lib/tmpfiles.d/legacy.conf - post your systemd bug but give me a moment to get some popcorn

Oh no, it comes from systemd :facepalm:

¹ EDIT: this issue could be solved by permissions root:uucp 01770 for /var/lock (/run/lock). I agree, alsa and dmraid aren't related to UUCP. But for some reason they use UUCP-style locks. I'm not sure their locks correspond to original purpose of /var/lock:

Lock files for devices and other resources shared by multiple applications.

Last edited by dimich (2025-01-06 23:11:09)

seth · 2025-01-07 10:22:12

It could, as suggested in my initial post.

Sorry, started at #5

malicious user can create lock file even without opening corresponding tty and provoke denial of service for legitime user program

Don't run malware. What if the malware runs as root or uucp?

But for some reason they use UUCP-style locks.

/var/lock is probably considered a generic location, https://en.wikipedia.org/wiki/Filesyste … y_Standard

https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch05s09.html wrote:

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…

Would then be read apart:
1. lock files of any kind go into /var/lock
2. also use this path to lock devices and your device lock has to look like…

I'd agree that this only makes sense if /var/lock was 1777 - rn. unprivileged processes of any kind will probably establish lock files in /tmp

dimich · 2025-01-07 14:20:18

seth wrote:

Don't run malware. What if the malware runs as root or uucp?

I consider GNU/Linux as a multi-user system.
Let Bob is a legitime user allowed to access serial port. Root has added Bob into uucp group, so Bob can open /dev/ttyS*.
Let Eve is a legitime user but not allowed to access serial port. She can't open /dev/ttyS*. But with 1777 on /var/lock she can touch /var/lock/LCK..ttyS* denying Bob's programs to use /dev/ttyS*.

As said above, the most proper solution in Linux would be to flock() device file directly, but this is not cross-platform.

seth wrote:

Lock files for devices and other resources shared by multiple applications, such as the serial device lock files that were originally found…

I think the key word is "resources". Currently I see "asound.state.lock" and "card0.lock" in /var/lock. "card0.lock" looks like a resource but "asound.state.lock" doesn't. What resource does it describe? Both files contain PID of process which is gone after initialization and doesn't exist anymore. Looks like alsactl uses this lock to avoid race with itself. I have no idea what resource dmraid may want to share with other applications.

seth · 2025-01-07 16:57:09

I consider GNU/Linux as a multi-user system.

Sure, but my point was that once you've a malicious agent in the mix, you cannot predict what's gonna happen anyway.

So the options are
1. /var/lock is UID0 only
2. /var/lock is 1777 and that implies everyone gets to write there
3. we believe that uucp is special and /var/lock is actually its and everything else is just abusing it.

1. is the status quo, breaks uucp GID
2. would fix (1) but allows unprivileged users to occupy locks against other unpriviled users
3. doesn't fit reality and the move away from /var/spool/uucp to the generic position doesn't suggest that was the idea.

Basically comes down to the conundrum of a bad spec where you have to pick your poison.

Arch Linux

#1 2020-12-17 13:11:21

/run and /run/lock permissions

#2 2020-12-17 13:57:23

Re: /run and /run/lock permissions

#3 2020-12-17 14:01:38

Re: /run and /run/lock permissions

#4 2020-12-17 14:42:42

Re: /run and /run/lock permissions

#5 2024-12-15 06:34:43

Re: /run and /run/lock permissions

#6 2024-12-15 08:40:33

Re: /run and /run/lock permissions

#7 2025-01-05 16:33:21

Re: /run and /run/lock permissions

#8 2025-01-06 12:18:15

Re: /run and /run/lock permissions

#9 2025-01-06 20:07:48

Re: /run and /run/lock permissions

#10 2025-01-07 10:22:12

Re: /run and /run/lock permissions

#11 2025-01-07 14:20:18

Re: /run and /run/lock permissions

#12 2025-01-07 16:57:09

Re: /run and /run/lock permissions

Board footer