linux-lockfiles
service
The /var/lock
directory on various Linux operating systems is considered outmoded.
It has two uses:
It was used by the old van Smoorenburg rc
system to try to prevent multiple instances of a single service from being run by accident.
Under an actual service manager, this is of course superfluous.
The service manager ensures that by its very nature.
It is used by subsystems that want to negotiate access to things like serial devices that can be used both for dial-out and for dial-in login.
The linux-lockfiles
service (which is only built and packaged on Linux operating systems, of course) is currently preset to "enabled" and its preset is packaged as one of a handful of "boot essential" services.
This service creates /run/lock
at bootstrap, which is where Linux operating systems nowadays point /var/lock
to with a symbolic link.
In theory, you should also create an /etc/fstab
entry for mounting a memory filesystem on top of /run/lock
(which the /etc/fstab
import subsytem will convert into a mount@-run-lock
service bundle, which in turn the linux-lockfiles
service bundle orders itself before).
This is because in theory unprivileged users can otherwise attack /run
(which they cannot write to) by filling up/run/lock
which (alas, for Debian Linux compatibility) they can write to.
In practice, this is just papering over the cracks, and the better approaches are:
Just do not use linux-lockfiles
at all, with a system-administrator-written preset (to disable it) that overrides the (intentionally low priority and overridable) "boot essentials" one that comes in the package.
Make /run/lock
not world-writable.
It is marked as "restricted write access", allowing the world to create files there with restricted permissions on how users can affect one anothers' files and directories.
This approach involves not making it world-writable at all, and letting only the programs that want to negotiate device access have the ability to create and delete files there.