[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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



Am 07.10.25 um 14:46 schrieb Henrik Ahlgren:
Simon Josefsson <simon@josefsson.org> 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


Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature


Reply to: