Why on earth would the permissions on /var/lock be something for systemd to decide?
this post was submitted on 23 Oct 2025
44 points (100.0% liked)
Linux
9902 readers
521 users here now
A community for everything relating to the GNU/Linux operating system (except the memes!)
Also, check out:
Original icon base courtesy of lewing@isc.tamu.edu and The GIMP
founded 2 years ago
MODERATORS
Why on earth would the permissions on /var/lock be something for systemd to decide?
Because – as LWN explains – there no longer is an overarching standards body who makes the decision, so anybody can make up their own.
Debian's continued use of UUCP-style locking does seem to be more than a little bit dated. The FHS 3.0 is clearly reaching the end of its useful life, if not actually expired.
Seems like Debian is more the outlier here.
there no longer is an overarching standards body who makes the decision
The creators of the FHS were never an overarching standards body. Despite its name, the FHS is more a set of conventions than a standard.
The closest standard that comes to mind is POSIX.
Reading more carefully I see that the real reason is "the /run directory is created as a tmpfs filesystem specifically for run-time files by systemd-tmpfiles.
I forgot that systemd had been allowed to take over /tmp and /run.
I forgot that systemd had been allowed to take over /tmp and /run.
According to Debian everyone is allowed to take over /run
The plan is to get rid of /run/lock entirely in the v259 release, though users (or distributions) can still retain the legacy behavior by adding a configuration file in /etc/tmpfiles.d to override systemd's defaults and create the directory with the desired permissions.
So systemd provides an option and it is intended to use it, if you disagree. I don't see a problem here. As long as it is an option and supported, its the distribution who have to make the change. Therefore Debian does not "override systemd change", but rather "Debian makes use of the normal systemd configuration". Am I understanding this wrong??
Although besides this, if Systemd wants to have a standard directory for lock files, that is only accessible by root, how about /var/lock/root subdirectory?
Systemd could add an option to make your computer run off fucking magic and some people would be pissed because it's "doing too much".
I genuinely just assume any knowledge about systemd is positive until someone provides a solid and definite reason for it being negative.
So much wasted time on Debian side. But, I am not sorry. They have a lot of guilt for this situation. They should vote better 11 years ago.