8 ms·

Debian Technical Committee overrides systemd change

227 points by birdculture 1y ago

raverbashing 1y ago
Debian discussions make political discussions seem quick and fast acting by comparison > He said that he uses cu ""almost constantly for interacting with embedded serial consoles on devices a USB connection away from my laptop"" Whyyyyyyyyyyyyyyy There are a million better ways of doing this.
- munchlax 1y ago
  cu is the regular way of doing it I don't see the problem. Minicom and even picocom are bloated compared to cu
- deleted 1y ago
  [deleted]
- kees99 1y ago
  I use GNU screen for that. Looking at cu, it looks to be just as tiny and has ssh-like tilda-escapes, including "~." to disconnect. Nice, gotta try it out, thanks!
  - ExoticPearTree 1y ago
    I got used to using minicom way way back. Has a nice TUI and can do stuff.
    - ta1243 1y ago
      I only moved to using screen about 2 years ago after over 2 decades of minicom
  - raverbashing 1y ago
    cu might be good for anything that you have a fixed config, otherwise I'll just go with minicom
- Hackbraten 1y ago
  One comment [0] highlights a point in favor of the current implementation: > create a lock file for every dial-in line to prevent its use by programs looking for a dial-out line. [0]: https://lwn.net/Articles/1042594/ https://lwn.net/Articles/1042594/
- MobiusHorizons 1y ago
  What would you suggest? Personally I find cu the closest to ssh in ergonomics to any of the tui serial terminal programs, and it’s easily available across unixes like FreeBSD or Mac OS, which is a bonus.
Hackbraten 1y ago
> The FHS 3.0 is clearly reaching the end of its useful life, if not actually expired. Interesting take. I think that the FHS is still extremely helpful for packagers, sysadmins and others so they won't stomp on each other's feet constantly. It helps set expectations and prevents unnecessary surprises. Just the fact that one particular FHS rule might be outdated or even harmful doesn't mean that the FHS as a whole has outlived its usefulness.
- Steltek 1y ago
  Standards are a double edged sword though. They are great for getting everyone to agree to the "most correct" answer. But they also freeze evolution in place. What happens when your standard doesn't support contemporary use cases? What if it's at direct odds with, say, modern security practices? FHS hasn't changed in years. Since then, sandboxing, containers, novel package schemes, and more are the zeitgeist. What does the FHS say about them?
  - Hackbraten 1y ago
    > What does the FHS say about them? Nothing keeps you from following the FHS inside your container or sandbox. Are you referring to the location where container images live? Then `/var/lib/containers/` and `/var/lib/containers/storage/` would be perfectly FHS compliant.
    - Steltek 1y ago
      The idea though is when you don't want to follow the FHS anymore, like systemd is doing. Systemd frustrates and angers people with Poettering's complete disregard for bug reports, tradition, and basic common courtesy. At the same time, change needed to happen and change is gonna hurt. And big changes can't wait until they're just as stable as the old system: does anyone develop software like that in their own careers? I try not to ship complete crap but "just as stable as v1" is never a goal.
      - hulitu 1y ago
ZeroConcerns 1y ago
Somehow I feel that if all the time that has been invested in debating and discussing this had been spent on patching the affected apps, the problem would be properly solved. I mean, yeah, I get it, systemd bad, democracy good, but these world-writable lock folders are actually a huge pain, and adding some shim code to upgrade to a more secure solution seems achievable?
- kees99 1y ago
  Genuinely curious - why would world-writeable directory be bad for security? Assuming of course, it's on a separate filesystem mounted with sensible options. Here's what I see from "grep /run/lock /proc/mounts" in sid: rw,nosuid,nodev,noexec,size=5120k
  - seanhunter 1y ago
    The classic is say you know a root process will write a file called foo.lock in /run/lock, and you (a bad person) have write access to that directory. Then you make foo.lock a symlink to some file (/bin/init or /bin/sh or ld.so for example would be very inconvenient choices) and when the root process writes its lock it destroys that file. Now obviously people these days generally know about that so hopefully don’t use predictable file names but that’s one way.
    - deleted 1y ago
      [deleted]
    - amiga386 1y ago
      > and when the root process writes its lock it destroys that file. Unless you do open("/run/lock/foo.lock", O_WRONLY|O_CREAT|O_EXCL|O_NOFOLLOW)
      - kees99 1y ago
        Yep. And for good measure, first open with O_CREAT as tempfile with random name, then rename() it to predictable "foo.lock".
tuhgdetzhh 1y ago
As always, it will just take another decade until debian has figured it out.
- gtsop 1y ago
  I am in no rush. I like something being stable.
- bayindirh 1y ago
  Considering I never had to reinstall a Debian system because it got bloated or broke one day, I can accept this slow-cooking approach. Even support them on this regard.
  - JohnFen 1y ago
    Yes, the slow-cooking approach is one of the main reasons why I prefer Debian.
  - simoncion 1y ago
    Gentoo Linux has quite a different approach than Debian [0] but after the first month or two (once my new-to-Linux ass figured out what it was doing) I've never had to reinstall any Gentoo system. [1] If you want what Debian provides, it's a poor choice for you... but -IME- it doesn't break on upgrade, unlike some Debian-derived distros I've tried in the past. [0] Something along the lines of "Always try to package exactly what's provided by upstream, try hard to get distro patches upstreamed, and try to have the latest available upstream release in the 'testing channel'.". [1] Well, I do have a machine that (aside from "side-loading" kernel updates from time to time) hasn't been updated in four years. While I'll try to update that one in the normal way, I'm probably going to need to reinstall.
- lousken 1y ago
  once it's ready they'll push it, that's how it should be
phoronixrly 1y ago
Non-clickbait title -- Debian Technical Committee overrides /run/lock permission change
- okanat 1y ago
  Yeah. I expected better from LWN.
  - ongy 1y ago
    IMO the interesting bit here isn't the specific technical change but the interpersonal one of overriding the maintainer(s) decision. Thus the title reflects the most interesting bit of the story.
- amiga386 1y ago
  More-clickbaity title -- Debian Technical Committee tells its doofus maintainers to stop worshipping Poettering so much
  - overfeed 1y ago
    "DTC serves crow to 2 systemd maintainers with a history of accepting money from Microsoft"
- lukeschlather 1y ago
  Why is that non-clickbait? Honestly "Debian Technical Committee overrides systemd /run/lock permission change" might be a better title than either, I don't know whether the thing or the actors are more interesting here. But you can only say so much in a title.
- dathinab 1y ago
  and also might be just temporary like overriding it now makes a lot of sense, there needs to be grace periods etc. but we live in a world where OSes have to become increasingly more resilient to misbehaving programs (mainly user programs, or "server programs" you can mostly isolate with services, service accounts/users etc.). And with continuous increases in both supply chain attacks and crappy AI code this will only get worse. And as such quotas/usage limits of a temp fs being shared between all user space programs like lvm2 and dmraid is kinda a bad idea. and for such robustness there aren't that many ways around this change, basically the alternatives are: - make /var/lock root only and break a very small number of programs which neither use flock nor follow the XDG spec (XDG_RUNTIME_DIR is where your user scoped locks go, like e.g. for wayland or pipewire) - change lvm2, dmraid, alsa(the low level parts) and a bunch of other things your could say are core OS components to use a different root only lock dir. Which is a lot of work and a lot of breaking changes, much more then the first approach.) - use a "magic" virtual file system which presents a single unified view of /var/lock, but under the hood magically separates them into different tempfs with different quotas (e.g. based on used id the file gets remapped to /run/user/{uid}, except roots gets a special folder and I guess another folder for "everything else"???) That looks like a lot of complexity to support a very small number of program doing something in a very (20+ years) outdated way. But similar tricks do exist in systemd (e.g. PrivateTemp). kinda only the first option makes sense but it's not that it needs to be done "NOW", like in a year would be fine too, but in 5 years probably not
baobun 1y ago
Debian systemd maintainer Luca Boccassi has recently pushed through and dismissed several problematic and undesired breakages as "niche cases" in a way I personally find antithetical to what I expect from Debian. I hope they have a change of mind in their approach.
- mx7zysuj4xew 1y ago
  [flagged]
- blueflow 1y ago
  This is usual systemd maintainer behavior. Poetterings "I don't consider it much of a problem" is legend: https://github.com/systemd/systemd/issues/5644 https://github.com/systemd/systemd/issues/5644
  - crest 1y ago
    The fool doesn't know how globbing works, but considers his uninformed guess good enough without testing it or reading (and understanding) the spec.
    - kelnos 1y ago
      To be fair, he does know how globbing works: ".*" should include "." and ".." under normal globbing rules. The 'rm' command (presumably) has a special case in it to avoid traversing those in recursive mode because doing so would be a footgun.
      - kps 1y ago
        To be fair, POSIX-compliant shells are allowed to exclude `.` and `..`, and some do, and POSIX says this may be required in the future. https://pubs.opengroup.org/onlinepubs/9799919799/utilities/V3_chap02.html#tag_19_14_03 https://pubs.opengroup.org/onlinepubs/9799919799/utilities/V...
        1y ago
bayindirh 1y ago
Can anyone tell why systemd developers run fast and loose with what they believe and bully everyone with a stick made out of their ideas?
- TacticalCoder 1y ago
  First before venting I'll say this: thanks to stuff like hypervisors, VMs, non-systemd distros, minimal immutable Linux distro like Talos (made to run Kubernetes with a minimum number of executable) and OCI containers where, by definition, PID 1 is not systemd, there's thankfully a real way out of systemd, even on a Linux stack. And I think more people should look into being, once again, 100% systemd-free. > Can anyone tell why systemd developers run fast and loose with what they believe and bully everyone with a stick made out of their ideas? Because the goal is to take control of Linux. That's why systemd is PID1. That's why Poettering works for Microsoft. The real question is: why was that ultra-convoluted xz backdoor attempt only working on Linux systems that did have systemd? People shall try to wag the dog saying "but it's because this and that made is so that xz was loaded by OpenSSH, it's got nothing to do with systemd". It's got everything to do with systemd. And the other question is: how many backdoors are operational, today, on systems that have systemd? Systemd is Microsoft-level bloat, running as PID 1, spreading its tentacles everywhere in Linux distros, definitely on purpose. Poettering is moreover an insufferable bully, as can be seen once again. From TFA: > So what do you recommend how to go on from here? Change Debian policy (as asked in #1111839), revert the change in systemd, find a Debian wide solution or let every package maintainer implement their own solution? I suggest Debian just drops systemd once and for all. Debian can still be made systemd-free but it's a hassle. Just make Debian systemd free once again. Meanwhile you'll find me running systemd-less distros on VMs and running containers giving the PID 1 finger to systemd. I can't wait to switch my Proxmox to FreeBSD's bhyve hypervisor (need to find the time to do it). But most of all: I cannot wait for the day a systemd-less hypervisor Linux like Proxmox comes out. It's coming and people who write stuff like: "Don't use Docker, use systemd this and systemd that" are misguided. systemd is to me the antithesis of what Linux stands for. I hope Debian gets pissed enough at some point to fully drop systemd. P.S: one of my machine runs this: https://www.devuan.org/ https://www.devuan.org/ and honestly it's totally fine. So yup: power to all those running systemd-less distros, BSDs, etc.
upofadown 1y ago
This part seems fairly editorial: >Debian Policy still cites the FHS, even though the FHS has gone unmaintained for more than a decade. What ongoing maintenance would a file system standard require? A successful standard of that type would have to remain static unless there was a serious issue to address. Regular changes are what the standard was intended to combat in the first place. >The specification was not so much finished as abandoned after FHS 3.0 was released... OK. >...though there is a slow-moving effort to revive and revise the standard as FHS 4.0, it has not yet produced any results. So it is not abandoned then. A slow moving process is exactly what you would want for the maintenance of a file system standard. >Meanwhile, in the absence of a current standard, systemd has spun off its file-hierarchy documentation to the Linux Userspace API (UAPI) Group as a specification. LWN covered that development in August, related to Fedora's search for an FHS successor. Ah. Systemd/Fedora want a standard that they can directly control without interference from others.
- Hendrikto 1y ago
  Counterpoint: Modern distro’s needs have evolved past the FHS in some cases, and everybody deviates from it slightly but incompatibly. A standard does no good if it does not reflect reality. I think it is a worthwhile effort to try to bring it back in line with actual real world usage.
  - cwillu 1y ago
    An interesting take in the context of systemd's deviation from it being the source of bugs because of real world usage that conflicts with systemd's changes.
  - sterlind 1y ago
    laughs in NixOS it's remarkable to me that NixOS manages to run so well despite breaking the FHS so thoroughly. and not just in superficial ways like not calling it /bin, I mean forsaking dynamic linking (hence /var/lib and /usr/lib), keeping man pages, resources and config bundled into the same derivation as the binary sometimes, and occasionally hacking up binary blobs to rewrite rpaths. on the other hand, there's a place for legacy distros too.
rwmj 1y ago
It's been a very long time since I heard about uucico (Unix-to-Unix Copy-In Copy-Out program, part of the UUCP suite). Glad to see it's still being shipped! I wonder if any network uses it.
- bwann 1y ago
  I've been running it the last year or two to get e-mail to a vintage DOS BBS that had a UUCP package. I was pleasantly surprised it was out of the box usable on both CentOS and Debian, and Postfix still ships with example UUCP email config.
pengaru 1y ago
Wow, talk about making a mountain of a mole hill. Letting upstream systemd single-handedly define what directories exist with what modes in your distro has never been the intended Modus Operandi. Debian has a huge selection of packages available for it and clearly is going to have more headaches when it comes to preserving compatibility with all that software. This is a trivial matter for Debian to handle appropriately, while systemd stays focused on its current priorities. I'm surprised this is being talked about at all outside the appropriate mailing lists... slow week for linux news?
pjdesno 1y ago
Is anyone surprised that the systemd folks basically said "fuck you, we'll do what we want to" to everyone else?
- scottlamb 1y ago
  > Is anyone surprised that the systemd folks basically said "fuck you, we'll do what we want to" to everyone else? I don't think that's an accurate paraphrase of "Consider this more a passing of the baton from upstream systemd to downstreams: if your distro wants this kind of legacy interface, then just add this via a distro-specific tmpfiles drop-in. But there's no point really in forcing anyone who has a more forward-looking view of the world to still carry that dir." That kind of drop-in is pretty routine, so I don't know why this became a big thing we're all discussing now.
  - ishouldbework 1y ago
    Well yes, but the complication is that Luca is both systemd developer and debian developer, so the passing of the baton did not really happen here.
- Barrin92 1y ago
  "everyone else" in this case is pretty much only the debian ecosystem because they insist on enforcing a serial lock policy from the 1980s. It's fine if Debian wants to move at the speed of a Soviet committee but I don't think it should be expected (or would be healthy) for systemd to move at the same pace. A software developer's primary job is to develop software for their users, not to comply with a third party distributor that repackages their software.
  - tuckerman 1y ago
    The beef isn't with systemd upstream which already has a very simple/boring workaround for this, it's with the debian package maintainer (some people here are wearing multiple hats). Really the whole raison d'etre of debian is move at this pace to prioritize stability/compatibility. If you don't like that philosophy there are other distros but a package maintainer's primary job is to repackage software for that distro (which presumably users have chosen for a reason), not comply with upstream.
jcalvinowens 1y ago
The "somebody might mailicuously exhaust memory via /run” argument seems silly IMHO... you can trivially put a hard limit on its size via the tmpfs mount option. I guess if you bend over backwards that's still a DOS in that new files can't be created in /run once it is full, but come on... There is support for quotas in tmpfs! /me runs and hides under desk to avoid fruit being thrown at me
- dathinab 1y ago
  The problem is /var/lock is still used for various system root components. Which includes services like lvm2, dmraid and audio drivers. So you need at least a different /var/lock for "root" and every one else. So you now can either fix all the root tooling to use a different lock folder. Which would break a lot of things. Or you break a very small number of very old tools which (mostly) decided to neither use use flock (from 1996) nor follow the XDG spec (XDF_RUNTIME_DIR) from 2003. So kinda obvious choice what way to go with ;), it just should be coordinated better and communicated better. And yes you want quotas on tempfs on XDF_RUNTIME_DIR, without question. At least for a system more robust against misbehaving programs. To be clear a lot of this security concerns have been irrelevant/ignored with thread models from the 2000th. But times (sadly) have changes and you shouldn't just blindly trust user space programs anymore. Even if we ignore malicious programs just thing about all the bugs AI will sneak in. And honestly I'm worried that Desktop Linux will fail to adopt to this changes. Server Linux is clearly adopting, but also more in the non-gnu Linux ecosystem while the more FSF/GNU parts of Linux seem mostly stuck in a past which doesn't look like it will have a future :/. This sucks without question but I just don't see a future without a lot of supply chain attack and AI coding induced crazy misbehavior of user space programs. PS: Even if you just want a steam deck with the same degree of robustness as console (i.e. a game going rogue will have a hard time to hang the console fully not matter what it does, i.e. you can always press the menu button and close/kill it) you need this kind of subtle changes. And many other.
  - jcalvinowens 1y ago
    > Which includes services like lvm2, dmraid and audio drivers. I know at least the first two have "ignore the lock" command line flags so you can get out of situations like /run being full. So whether it's a DOS depends on how you define DOS :) > it just should be coordinated better and communicated better I mean, that's the thing. I don't disagree it should be fixed. But is it really an important enough problem it justifies breaking users now? Not for me...
krick 1y ago
I still cannot understand how it came about that everyone adopted systemd, despite it being a showcase of the most selfish, reckless and irresponsible maintainership ever. And it's not like it's something new, it's been like that for what, 10, 15 years now?
senshan 1y ago
> Any process could write as much as it wanted to /run, which > could effectively DoS the system by exhausting space or inodes Does ulimit and quotas sufficiently address this concern?
jrmg 1y ago
Another conflict: in Debian Trixie (current stable release), when you run `systemctl status …` you’re given the rather scary warnings: State: degraded … Tainted: unmerged-bin This is because Debian has a separate /usr/bin and /usr/sbin. There are no plans to either back off this warning by the systemd maintainers, or to patch it out by the Debian maintainers, and also no plans to merge /usr/sbin and /usr/bin. So we’re left with the absurd situation that Debian users are being told the default clean install is ‘degraded’ and ‘tainted’ by its main init system! https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1085370 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1085370 https://github.com/systemd/systemd/issues/35438 https://github.com/systemd/systemd/issues/35438
- hnarn 1y ago
  [flagged]
- voakbasda 1y ago
  If this is the case, I am surprised no one has patched this anti-feature out of the source. Both sides made that suggestion directly in the bug reports you linked. I expect it should be positively trivial to implement a patch, but someone must step up and do the work.
  - detaro 1y ago
    systemd upstream says "distros can patch it out if they want", the debian package maintainer doesn't want to carry a patch. "Someone needs to write a patch" is not the problem here.
    - voakbasda 1y ago
      Oops. I misread Luca’s reply as willingness to accept a patch, but he said to submit one upstream - where they explicitly don’t want it. So, yeah, deadlock. Has anyone pushed on this issue? If a patch exists and upstream explicitly says it belongs in the distro, then I expect an explanation from the maintainer(s) would need to be presented to detail exactly why it’s either unsuitable/unmaintainable or left better as-is.
waynesonfire 1y ago
The last paragraph in the article states how Fedora uses lockdev(3) to somehow address the issue. It's not clear to me how a library that exposes a standardized management interface to these locks enables non-root users to create them without a world writable lock directory. Is it that lockdev(3) allows the system to use a different directory? Secondly, it's suggested that the /run/lock directory and/or the solution of acquiring a lock for a shared resources is dated -- but, no mention of the "modern" way to address this? Is it implied that systemd offers a solution to this? What is it? PS lockdev has such a poorly written manpage.
tannhaeuser 1y ago
They should've never accepted systemd into Debian, or other submarines to monopolize knowledge around RH/IBM and steal attention away from original software packages (gnome, wayland, podman, hell even rpm, etc.)

227 points by birdculture 1y ago

Debian discussions make political discussions seem quick and fast acting by comparison > He said that he uses cu ""almost constantly for interacting with embedded serial consoles on devices a USB connection away from my laptop"" Whyyyyyyyyyyyyyyy There are a million better ways of doing this.

munchlax 1y ago
cu is the regular way of doing it I don't see the problem. Minicom and even picocom are bloated compared to cu
deleted 1y ago
[deleted]
kees99 1y ago
I use GNU screen for that. Looking at cu, it looks to be just as tiny and has ssh-like tilda-escapes, including "~." to disconnect. Nice, gotta try it out, thanks!
- ExoticPearTree 1y ago
  I got used to using minicom way way back. Has a nice TUI and can do stuff.
  - ta1243 1y ago
    I only moved to using screen about 2 years ago after over 2 decades of minicom
- raverbashing 1y ago
  cu might be good for anything that you have a fixed config, otherwise I'll just go with minicom
Hackbraten 1y ago
One comment [0] highlights a point in favor of the current implementation: > create a lock file for every dial-in line to prevent its use by programs looking for a dial-out line. [0]: https://lwn.net/Articles/1042594/ https://lwn.net/Articles/1042594/
MobiusHorizons 1y ago
What would you suggest? Personally I find cu the closest to ssh in ergonomics to any of the tui serial terminal programs, and it’s easily available across unixes like FreeBSD or Mac OS, which is a bonus.

Hackbraten 1y ago

> The FHS 3.0 is clearly reaching the end of its useful life, if not actually expired. Interesting take. I think that the FHS is still extremely helpful for packagers, sysadmins and others so they won't stomp on each other's feet constantly. It helps set expectations and prevents unnecessary surprises. Just the fact that one particular FHS rule might be outdated or even harmful doesn't mean that the FHS as a whole has outlived its usefulness.

Steltek 1y ago
Standards are a double edged sword though. They are great for getting everyone to agree to the "most correct" answer. But they also freeze evolution in place. What happens when your standard doesn't support contemporary use cases? What if it's at direct odds with, say, modern security practices? FHS hasn't changed in years. Since then, sandboxing, containers, novel package schemes, and more are the zeitgeist. What does the FHS say about them?
- Hackbraten 1y ago
  > What does the FHS say about them? Nothing keeps you from following the FHS inside your container or sandbox. Are you referring to the location where container images live? Then `/var/lib/containers/` and `/var/lib/containers/storage/` would be perfectly FHS compliant.
  - Steltek 1y ago
    The idea though is when you don't want to follow the FHS anymore, like systemd is doing. Systemd frustrates and angers people with Poettering's complete disregard for bug reports, tradition, and basic common courtesy. At the same time, change needed to happen and change is gonna hurt. And big changes can't wait until they're just as stable as the old system: does anyone develop software like that in their own careers? I try not to ship complete crap but "just as stable as v1" is never a goal.
    - hulitu 1y ago

ZeroConcerns 1y ago

Somehow I feel that if all the time that has been invested in debating and discussing this had been spent on patching the affected apps, the problem would be properly solved. I mean, yeah, I get it, systemd bad, democracy good, but these world-writable lock folders are actually a huge pain, and adding some shim code to upgrade to a more secure solution seems achievable?

kees99 1y ago
Genuinely curious - why would world-writeable directory be bad for security? Assuming of course, it's on a separate filesystem mounted with sensible options. Here's what I see from "grep /run/lock /proc/mounts" in sid: rw,nosuid,nodev,noexec,size=5120k
- seanhunter 1y ago
  The classic is say you know a root process will write a file called foo.lock in /run/lock, and you (a bad person) have write access to that directory. Then you make foo.lock a symlink to some file (/bin/init or /bin/sh or ld.so for example would be very inconvenient choices) and when the root process writes its lock it destroys that file. Now obviously people these days generally know about that so hopefully don’t use predictable file names but that’s one way.
  - deleted 1y ago
    [deleted]
  - amiga386 1y ago
    > and when the root process writes its lock it destroys that file. Unless you do open("/run/lock/foo.lock", O_WRONLY|O_CREAT|O_EXCL|O_NOFOLLOW)
    - kees99 1y ago
      Yep. And for good measure, first open with O_CREAT as tempfile with random name, then rename() it to predictable "foo.lock".

tuhgdetzhh 1y ago

As always, it will just take another decade until debian has figured it out.

gtsop 1y ago
I am in no rush. I like something being stable.
bayindirh 1y ago
Considering I never had to reinstall a Debian system because it got bloated or broke one day, I can accept this slow-cooking approach. Even support them on this regard.
- JohnFen 1y ago
  Yes, the slow-cooking approach is one of the main reasons why I prefer Debian.
- simoncion 1y ago
  Gentoo Linux has quite a different approach than Debian [0] but after the first month or two (once my new-to-Linux ass figured out what it was doing) I've never had to reinstall any Gentoo system. [1] If you want what Debian provides, it's a poor choice for you... but -IME- it doesn't break on upgrade, unlike some Debian-derived distros I've tried in the past. [0] Something along the lines of "Always try to package exactly what's provided by upstream, try hard to get distro patches upstreamed, and try to have the latest available upstream release in the 'testing channel'.". [1] Well, I do have a machine that (aside from "side-loading" kernel updates from time to time) hasn't been updated in four years. While I'll try to update that one in the normal way, I'm probably going to need to reinstall.
lousken 1y ago
once it's ready they'll push it, that's how it should be

phoronixrly 1y ago

Non-clickbait title -- Debian Technical Committee overrides /run/lock permission change

okanat 1y ago
Yeah. I expected better from LWN.
- ongy 1y ago
  IMO the interesting bit here isn't the specific technical change but the interpersonal one of overriding the maintainer(s) decision. Thus the title reflects the most interesting bit of the story.
amiga386 1y ago
More-clickbaity title -- Debian Technical Committee tells its doofus maintainers to stop worshipping Poettering so much
- overfeed 1y ago
  "DTC serves crow to 2 systemd maintainers with a history of accepting money from Microsoft"
lukeschlather 1y ago
Why is that non-clickbait? Honestly "Debian Technical Committee overrides systemd /run/lock permission change" might be a better title than either, I don't know whether the thing or the actors are more interesting here. But you can only say so much in a title.
dathinab 1y ago
and also might be just temporary like overriding it now makes a lot of sense, there needs to be grace periods etc. but we live in a world where OSes have to become increasingly more resilient to misbehaving programs (mainly user programs, or "server programs" you can mostly isolate with services, service accounts/users etc.). And with continuous increases in both supply chain attacks and crappy AI code this will only get worse. And as such quotas/usage limits of a temp fs being shared between all user space programs like lvm2 and dmraid is kinda a bad idea. and for such robustness there aren't that many ways around this change, basically the alternatives are: - make /var/lock root only and break a very small number of programs which neither use flock nor follow the XDG spec (XDG_RUNTIME_DIR is where your user scoped locks go, like e.g. for wayland or pipewire) - change lvm2, dmraid, alsa(the low level parts) and a bunch of other things your could say are core OS components to use a different root only lock dir. Which is a lot of work and a lot of breaking changes, much more then the first approach.) - use a "magic" virtual file system which presents a single unified view of /var/lock, but under the hood magically separates them into different tempfs with different quotas (e.g. based on used id the file gets remapped to /run/user/{uid}, except roots gets a special folder and I guess another folder for "everything else"???) That looks like a lot of complexity to support a very small number of program doing something in a very (20+ years) outdated way. But similar tricks do exist in systemd (e.g. PrivateTemp). kinda only the first option makes sense but it's not that it needs to be done "NOW", like in a year would be fine too, but in 5 years probably not

baobun 1y ago

Debian systemd maintainer Luca Boccassi has recently pushed through and dismissed several problematic and undesired breakages as "niche cases" in a way I personally find antithetical to what I expect from Debian. I hope they have a change of mind in their approach.

mx7zysuj4xew 1y ago
[flagged]
blueflow 1y ago
This is usual systemd maintainer behavior. Poetterings "I don't consider it much of a problem" is legend: https://github.com/systemd/systemd/issues/5644 https://github.com/systemd/systemd/issues/5644
- crest 1y ago
  The fool doesn't know how globbing works, but considers his uninformed guess good enough without testing it or reading (and understanding) the spec.
  - kelnos 1y ago
    To be fair, he does know how globbing works: ".*" should include "." and ".." under normal globbing rules. The 'rm' command (presumably) has a special case in it to avoid traversing those in recursive mode because doing so would be a footgun.
    - kps 1y ago
      To be fair, POSIX-compliant shells are allowed to exclude `.` and `..`, and some do, and POSIX says this may be required in the future. https://pubs.opengroup.org/onlinepubs/9799919799/utilities/V3_chap02.html#tag_19_14_03 https://pubs.opengroup.org/onlinepubs/9799919799/utilities/V...
      - 1y ago

bayindirh 1y ago

Can anyone tell why systemd developers run fast and loose with what they believe and bully everyone with a stick made out of their ideas?

TacticalCoder 1y ago
First before venting I'll say this: thanks to stuff like hypervisors, VMs, non-systemd distros, minimal immutable Linux distro like Talos (made to run Kubernetes with a minimum number of executable) and OCI containers where, by definition, PID 1 is not systemd, there's thankfully a real way out of systemd, even on a Linux stack. And I think more people should look into being, once again, 100% systemd-free. > Can anyone tell why systemd developers run fast and loose with what they believe and bully everyone with a stick made out of their ideas? Because the goal is to take control of Linux. That's why systemd is PID1. That's why Poettering works for Microsoft. The real question is: why was that ultra-convoluted xz backdoor attempt only working on Linux systems that did have systemd? People shall try to wag the dog saying "but it's because this and that made is so that xz was loaded by OpenSSH, it's got nothing to do with systemd". It's got everything to do with systemd. And the other question is: how many backdoors are operational, today, on systems that have systemd? Systemd is Microsoft-level bloat, running as PID 1, spreading its tentacles everywhere in Linux distros, definitely on purpose. Poettering is moreover an insufferable bully, as can be seen once again. From TFA: > So what do you recommend how to go on from here? Change Debian policy (as asked in #1111839), revert the change in systemd, find a Debian wide solution or let every package maintainer implement their own solution? I suggest Debian just drops systemd once and for all. Debian can still be made systemd-free but it's a hassle. Just make Debian systemd free once again. Meanwhile you'll find me running systemd-less distros on VMs and running containers giving the PID 1 finger to systemd. I can't wait to switch my Proxmox to FreeBSD's bhyve hypervisor (need to find the time to do it). But most of all: I cannot wait for the day a systemd-less hypervisor Linux like Proxmox comes out. It's coming and people who write stuff like: "Don't use Docker, use systemd this and systemd that" are misguided. systemd is to me the antithesis of what Linux stands for. I hope Debian gets pissed enough at some point to fully drop systemd. P.S: one of my machine runs this: https://www.devuan.org/ https://www.devuan.org/ and honestly it's totally fine. So yup: power to all those running systemd-less distros, BSDs, etc.

upofadown 1y ago

This part seems fairly editorial: >Debian Policy still cites the FHS, even though the FHS has gone unmaintained for more than a decade. What ongoing maintenance would a file system standard require? A successful standard of that type would have to remain static unless there was a serious issue to address. Regular changes are what the standard was intended to combat in the first place. >The specification was not so much finished as abandoned after FHS 3.0 was released... OK. >...though there is a slow-moving effort to revive and revise the standard as FHS 4.0, it has not yet produced any results. So it is not abandoned then. A slow moving process is exactly what you would want for the maintenance of a file system standard. >Meanwhile, in the absence of a current standard, systemd has spun off its file-hierarchy documentation to the Linux Userspace API (UAPI) Group as a specification. LWN covered that development in August, related to Fedora's search for an FHS successor. Ah. Systemd/Fedora want a standard that they can directly control without interference from others.

Hendrikto 1y ago
Counterpoint: Modern distro’s needs have evolved past the FHS in some cases, and everybody deviates from it slightly but incompatibly. A standard does no good if it does not reflect reality. I think it is a worthwhile effort to try to bring it back in line with actual real world usage.
- cwillu 1y ago
  An interesting take in the context of systemd's deviation from it being the source of bugs because of real world usage that conflicts with systemd's changes.
- sterlind 1y ago
  laughs in NixOS it's remarkable to me that NixOS manages to run so well despite breaking the FHS so thoroughly. and not just in superficial ways like not calling it /bin, I mean forsaking dynamic linking (hence /var/lib and /usr/lib), keeping man pages, resources and config bundled into the same derivation as the binary sometimes, and occasionally hacking up binary blobs to rewrite rpaths. on the other hand, there's a place for legacy distros too.

rwmj 1y ago

It's been a very long time since I heard about uucico (Unix-to-Unix Copy-In Copy-Out program, part of the UUCP suite). Glad to see it's still being shipped! I wonder if any network uses it.

bwann 1y ago
I've been running it the last year or two to get e-mail to a vintage DOS BBS that had a UUCP package. I was pleasantly surprised it was out of the box usable on both CentOS and Debian, and Postfix still ships with example UUCP email config.

pengaru 1y ago

Wow, talk about making a mountain of a mole hill. Letting upstream systemd single-handedly define what directories exist with what modes in your distro has never been the intended Modus Operandi. Debian has a huge selection of packages available for it and clearly is going to have more headaches when it comes to preserving compatibility with all that software. This is a trivial matter for Debian to handle appropriately, while systemd stays focused on its current priorities. I'm surprised this is being talked about at all outside the appropriate mailing lists... slow week for linux news?

pjdesno 1y ago

Is anyone surprised that the systemd folks basically said "fuck you, we'll do what we want to" to everyone else?

scottlamb 1y ago
> Is anyone surprised that the systemd folks basically said "fuck you, we'll do what we want to" to everyone else? I don't think that's an accurate paraphrase of "Consider this more a passing of the baton from upstream systemd to downstreams: if your distro wants this kind of legacy interface, then just add this via a distro-specific tmpfiles drop-in. But there's no point really in forcing anyone who has a more forward-looking view of the world to still carry that dir." That kind of drop-in is pretty routine, so I don't know why this became a big thing we're all discussing now.
- ishouldbework 1y ago
  Well yes, but the complication is that Luca is both systemd developer and debian developer, so the passing of the baton did not really happen here.
Barrin92 1y ago
"everyone else" in this case is pretty much only the debian ecosystem because they insist on enforcing a serial lock policy from the 1980s. It's fine if Debian wants to move at the speed of a Soviet committee but I don't think it should be expected (or would be healthy) for systemd to move at the same pace. A software developer's primary job is to develop software for their users, not to comply with a third party distributor that repackages their software.
- tuckerman 1y ago
  The beef isn't with systemd upstream which already has a very simple/boring workaround for this, it's with the debian package maintainer (some people here are wearing multiple hats). Really the whole raison d'etre of debian is move at this pace to prioritize stability/compatibility. If you don't like that philosophy there are other distros but a package maintainer's primary job is to repackage software for that distro (which presumably users have chosen for a reason), not comply with upstream.

jcalvinowens 1y ago

The "somebody might mailicuously exhaust memory via /run” argument seems silly IMHO... you can trivially put a hard limit on its size via the tmpfs mount option. I guess if you bend over backwards that's still a DOS in that new files can't be created in /run once it is full, but come on... There is support for quotas in tmpfs! /me runs and hides under desk to avoid fruit being thrown at me

dathinab 1y ago
The problem is /var/lock is still used for various system root components. Which includes services like lvm2, dmraid and audio drivers. So you need at least a different /var/lock for "root" and every one else. So you now can either fix all the root tooling to use a different lock folder. Which would break a lot of things. Or you break a very small number of very old tools which (mostly) decided to neither use use flock (from 1996) nor follow the XDG spec (XDF_RUNTIME_DIR) from 2003. So kinda obvious choice what way to go with ;), it just should be coordinated better and communicated better. And yes you want quotas on tempfs on XDF_RUNTIME_DIR, without question. At least for a system more robust against misbehaving programs. To be clear a lot of this security concerns have been irrelevant/ignored with thread models from the 2000th. But times (sadly) have changes and you shouldn't just blindly trust user space programs anymore. Even if we ignore malicious programs just thing about all the bugs AI will sneak in. And honestly I'm worried that Desktop Linux will fail to adopt to this changes. Server Linux is clearly adopting, but also more in the non-gnu Linux ecosystem while the more FSF/GNU parts of Linux seem mostly stuck in a past which doesn't look like it will have a future :/. This sucks without question but I just don't see a future without a lot of supply chain attack and AI coding induced crazy misbehavior of user space programs. PS: Even if you just want a steam deck with the same degree of robustness as console (i.e. a game going rogue will have a hard time to hang the console fully not matter what it does, i.e. you can always press the menu button and close/kill it) you need this kind of subtle changes. And many other.
- jcalvinowens 1y ago
  > Which includes services like lvm2, dmraid and audio drivers. I know at least the first two have "ignore the lock" command line flags so you can get out of situations like /run being full. So whether it's a DOS depends on how you define DOS :) > it just should be coordinated better and communicated better I mean, that's the thing. I don't disagree it should be fixed. But is it really an important enough problem it justifies breaking users now? Not for me...

krick 1y ago

I still cannot understand how it came about that everyone adopted systemd, despite it being a showcase of the most selfish, reckless and irresponsible maintainership ever. And it's not like it's something new, it's been like that for what, 10, 15 years now?

senshan 1y ago

> Any process could write as much as it wanted to /run, which > could effectively DoS the system by exhausting space or inodes Does ulimit and quotas sufficiently address this concern?

jrmg 1y ago

Another conflict: in Debian Trixie (current stable release), when you run `systemctl status …` you’re given the rather scary warnings: State: degraded … Tainted: unmerged-bin This is because Debian has a separate /usr/bin and /usr/sbin. There are no plans to either back off this warning by the systemd maintainers, or to patch it out by the Debian maintainers, and also no plans to merge /usr/sbin and /usr/bin. So we’re left with the absurd situation that Debian users are being told the default clean install is ‘degraded’ and ‘tainted’ by its main init system! https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1085370 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1085370 https://github.com/systemd/systemd/issues/35438 https://github.com/systemd/systemd/issues/35438

hnarn 1y ago
[flagged]
voakbasda 1y ago
If this is the case, I am surprised no one has patched this anti-feature out of the source. Both sides made that suggestion directly in the bug reports you linked. I expect it should be positively trivial to implement a patch, but someone must step up and do the work.
- detaro 1y ago
  systemd upstream says "distros can patch it out if they want", the debian package maintainer doesn't want to carry a patch. "Someone needs to write a patch" is not the problem here.
  - voakbasda 1y ago
    Oops. I misread Luca’s reply as willingness to accept a patch, but he said to submit one upstream - where they explicitly don’t want it. So, yeah, deadlock. Has anyone pushed on this issue? If a patch exists and upstream explicitly says it belongs in the distro, then I expect an explanation from the maintainer(s) would need to be presented to detail exactly why it’s either unsuitable/unmaintainable or left better as-is.

waynesonfire 1y ago

The last paragraph in the article states how Fedora uses lockdev(3) to somehow address the issue. It's not clear to me how a library that exposes a standardized management interface to these locks enables non-root users to create them without a world writable lock directory. Is it that lockdev(3) allows the system to use a different directory? Secondly, it's suggested that the /run/lock directory and/or the solution of acquiring a lock for a shared resources is dated -- but, no mention of the "modern" way to address this? Is it implied that systemd offers a solution to this? What is it? PS lockdev has such a poorly written manpage.

tannhaeuser 1y ago

They should've never accepted systemd into Debian, or other submarines to monopolize knowledge around RH/IBM and steal attention away from original software packages (gnome, wayland, podman, hell even rpm, etc.)