Debian Technical Committee overrides systemd change

Original Article ↗ Hacker News Discussion ↗

Context: /run/lock permission change and Debian TC override

  • systemd upstream made /run/lock root‑writable only, citing security and robustness.
  • Debian’s systemd maintainer followed upstream, which broke older software assuming a world‑writable lock directory.
  • The Debian Technical Committee overrode this, restoring the previous behavior for now in the interest of stability and compatibility.
  • Some argue this is exactly Debian’s role; others see it as an unhealthy clash between upstream and a distro maintainer wearing both hats.

Legacy serial tools and lockfile behavior

  • A side thread debates serial console tools: cu vs minicom, picocom, screen. Some prefer cu for simplicity and ssh‑like escapes; others find it outdated.
  • The traditional UUCP‑style locking model (/var/lock, LCK..device) is still used by some tools; others use flock or newer mechanisms.

Security vs compatibility of world‑writable lock dirs

  • Pro‑change side:
    • World‑writable shared dirs are long known footguns: symlink attacks on root processes and DoS by exhausting tmpfs inodes/space.
    • Modern practice favors flock() and per‑user runtimes ($XDG_RUNTIME_DIR = /run/user/$uid) instead of global /var/lock.
    • Given increased threat models (untrusted code, supply‑chain issues, AI‑generated bugs), the old design is seen as indefensible long‑term.
  • Skeptical side:
    • The concrete risk from /var/lock is seen as theoretical or niche compared to other attack surfaces.
    • Many legacy or unmaintained tools cannot realistically be fixed; making /run/lock root‑only forces awkward workarounds or containers.
    • Some suggest separate mounts or quotas as less disruptive mitigations.

FHS, UAPI, and filesystem layout politics

  • One camp says FHS 3.0 is effectively abandoned: it hasn’t tracked /run, /sys, /run/user, /usr‑merge, or container realities, and contains obsolete details (/var/games, /var/mail, UUCP locks).
  • Another argues a filesystem standard should be slow‑moving; “not updated” can mean “mature”, not “dead”.
  • systemd’s file‑hierarchy spec and the Linux UAPI Group are seen by some as a needed de‑facto successor; others view them as systemd/Fedora capturing standardization to legitimize their own layout choices.

Debian culture and pace vs “modernization”

  • Many commenters defend Debian’s “slow‑cooking” ethos: they value never having to reinstall and high upgrade stability, even if it delays changes like this.
  • Others criticize Debian for resisting long‑foreseen cleanups (global writable dirs, /usr merge) and making life hard for upstreams.

Views on systemd and its maintainers

  • Strongly mixed sentiment:
    • Supporters credit systemd with dramatically better service management, logging, and consistency across distros.
    • Critics see a pattern of arrogance, dismissing “niche” breakages, using warnings like “degraded/tainted” for unmerged /usr, and pushing the world to conform to systemd’s assumptions.
    • Some inject distrust over large‑vendor employment and speculate about motives; others push back, noting that upstream reasonably says “distros can patch behavior they want”.

Overall framing of the conflict

  • One reading: a straightforward distro‑vs‑upstream division of labor—systemd tightens defaults, Debian restores legacy behavior for its users.
  • Another reading: a recurring governance and culture clash where systemd unilaterally redefines long‑standing interfaces and Debian must either absorb the fallout or actively resist.