Re: Bug#1115317: Technical Committee resolution on /var/lock and systemd

Michael Biebl <[email protected]> Tue, 7 Oct 2025 15:44:09 +0200

Newsgroups	gmane.linux.debian.devel.ctte
Message-ID	<b151ff64-30bd-4dd1-a878-49da23da5e85__26168.9974273153$1759845644$gmane$org@debian.org>

Am 07.10.25 um 14:46 schrieb Henrik Ahlgren:
> Simon Josefsson <[email protected]> writes:
> 
>> Then all packages that need /var/lock in Debian can depend on this
>> 'var-lock' package, which would also allow us to better track which
>> packages still use this suboptimal interface for device locking.  Or
>> just move the directory to 'base-files' or similar.
> 
> /var/lock is already owned by base-files, and it is a symlink pointing
> to /run/lock, which is created by systemd
> (/usr/lib/tmpfiles.d/debian.conf).
> 
> Systemd also has has a tmpfiles.d snipped called legacy.conf
> that attempt to create a relative symlink:
> 
> d /run/lock 0755 root root -
> L /var/lock - - - - ../run/lock
> 
> Since tmpfiles.d/debian.conf already has an entry for /run/lock,
> systemd-tmpfiles-setup.service complains:
> 
> Oct 05 23:15:18 noux systemd-tmpfiles[689]: /usr/lib/tmpfiles.d/legacy.conf:14: Duplicate line for path "/run/lock", ignoring.

As former systemd maintainer I want to provide some further details:

/var/lock being a symlink to /run/lock is an important detail.

Simply making /run/lock writable by arbitrary users or programs opens up 
/run (which is memory based) to DoS, so this should be avoided.

In the past, /run/lock was a separate tmpfs with pretty tight memory 
constraints (it could only take up to 5 MB).

This was a Debian specific patch which made /run/lock an "API fs", i.e. 
it was one of the first actions systemd did when starting up, i.e. it 
was basically available during the complete run-time of the system.

It was implemented via [0]

bluca dropped this patch and turned this into a run-lock.mount unit in [1].

This has the downside, that the /run/lock tmpfs is mounted much later 
during the boot process, so services needed to declare an explicit 
ordering against run-lock.mount if they needed that directory.
It also didn't account for processes that were spawned by users, i.e. by 
interactive shells and also cron like stuff.

bluca dropped this run-lock.mount unit in [2].

Given the ctte ruling, I would like to see /run/lock being a separate 
tmpfs again until all software requiring it has been updated.

Michael

[0] 
https://salsa.debian.org/systemd-team/systemd/-/blob/debian/bookworm/debian/patches/debian/Make-run-lock-tmpfs-an-API-fs.patch?ref_type=heads
[1] 
https://salsa.debian.org/systemd-team/systemd/-/commit/d3f9a1f928a9f8ae6d917ec06cff651a03dfb8dc
[2] 
https://salsa.debian.org/systemd-team/systemd/-/commit/7ef47f9f6b09eb981cbcd0d7514b6793702ab8a8

OpenPGP_signature.asc (application/pgp-signature, 840 B)