Most active commenters
  • growse(3)

←back to thread

466 points CoolCold | 18 comments | | HN request time: 0.884s | source | bottom
Show context
kbar13 ◴[] No.40208219[source]
systemd has been a net positive for the linux ecosystem. remember when you had to write bash scripts to start, stop, restart services and handle any other signals you want to send it? nowadays it's a unit file (basically just an ini file) away with relatively straightforward API. and you can actually declare startup dependencies and other useful relationships past just "prepend a number signifying when it should run globally to the front of the filename". it's provided an extensible platform with which higher level orchestration frameworks like ansible / ignition can easily templatize services or other system configuration.

since the beginning of systemd people have moaned about how complex it is and how we're reinventing the wheel. yet time and time again the people actually working on the project show that the solution they've come up with is the result of the problem they're facing on a daily basis. it's quite annoying that the armchair linux experts complain about how "lol systemd is so stupid for reinventing the wheel, give me my shell scripts back", maybe think about whether or not you have a legitimate issue not being addressed by the solution proposed or if you are just getting rage baited by a headline.

replies(17): >>40208249 #>>40208286 #>>40208374 #>>40208481 #>>40209110 #>>40209185 #>>40212620 #>>40212965 #>>40214704 #>>40214800 #>>40214923 #>>40215163 #>>40215552 #>>40215793 #>>40216445 #>>40217144 #>>40217617 #
Faaak ◴[] No.40208286[source]
Yeah, basically I've found that the people the more vocal against systemd are either not really knowing how it works behind the scenes, and just criticizing for the sake of it (or because other people do so), or criticizing from an ideological point of view (do one thing and do it well). They see systemd as an octopus, not following the unix ideology. Which I don't really agree tbh
replies(4): >>40208422 #>>40209002 #>>40212740 #>>40218038 #
StimDeck[dead post] ◴[] No.40209002[source]
[flagged]
1. growse ◴[] No.40209034[source]
I think dynamic linking pre-dates systemd by quite a number of years.
replies(1): >>40209169 #
2. StimDeck ◴[] No.40209169[source]
SSH being linked to XZ doesn’t.
replies(3): >>40209743 #>>40214774 #>>40214989 #
3. growse ◴[] No.40209743[source]
So aim your ire at the distributions who (I agree) cocked this one up. "Take a library dependency to implement basic functionality" is not a systemd mentality, it's pernicious throughout software development - see leftPad as another example.
replies(2): >>40215111 #>>40215112 #
4. SR2Z ◴[] No.40214774[source]
Why wouldn't SSH be linked to XZ? Isn't it supported as a compression method for connections?
replies(2): >>40215048 #>>40224950 #
5. tommiegannert ◴[] No.40214989[source]
My Ubuntu /usr/sbin/sshd already links to libz, liblzma, liblz4 and libzstd. I don't see why linking to libxz would be so outrageous. All-in-all, ldd reports 26 libraries.

They attacked the weakest link, and systemd was just a small pawn in that game. Sure, a smaller attack surface is better, but it's not like OpenSSHd has a small attack surface even without libsystemd. Not even in projects with a similar possibility of obscure "test data."

replies(3): >>40215680 #>>40218362 #>>40220509 #
6. yjftsjthsd-h ◴[] No.40215048{3}[source]
IIRC, xz was used by a systemd library, and that systemd library got added to sshd so it could tell systemd when it had started or something like that. SSH itself doesn't use xz.
replies(2): >>40217025 #>>40223529 #
7. ◴[] No.40215111{3}[source]
8. immibis ◴[] No.40215112{3}[source]
"Put everything in one big ball" is systemd mentality AND something that enabled the xz exploit to work.
replies(1): >>40216864 #
9. michaelmrose ◴[] No.40215680{3}[source]
In void it links 11 and includes only libz of the items you listed.
10. growse ◴[] No.40216864{4}[source]
Lots of things enabled the xz exploit to work.

If the lesson you take from xz is "systemd bad" then you've really missed the wood for the trees.

replies(1): >>40217338 #
11. riddley ◴[] No.40217025{4}[source]
xz is a compression library.
replies(1): >>40217925 #
12. immibis ◴[] No.40217338{5}[source]
It's one of many things to consider. Think of it as sandboxing, or attack surface reduction. Should we expose everything to everything else, or should it be on a need-to-know basis?
13. yjftsjthsd-h ◴[] No.40217925{5}[source]
I'm aware? It's a compression library that is used by systemd, including in a systemd library that got added to sshd in some distros.
14. t-3 ◴[] No.40218362{3}[source]
On OpenBSD it links 4 libraries. On my crux linux installation, 7.
15. jwilk ◴[] No.40220509{3}[source]
> My Ubuntu /usr/sbin/sshd already links to libz, liblzma, liblz4 and libzstd.

Except for libz, they are only linked indirectly through libsystemd.

> I don't see why linking to libxz would be so outrageous

The XZ Utils library is called liblzma, not libxz.

replies(1): >>40220650 #
16. tommiegannert ◴[] No.40220650{4}[source]
> Except for libz, they are only linked indirectly though libsystemd.

Ah, that invalidates my point re. obscure test data. Sloppy use of ldd. (I'm guessing it would be much harder making such an attack on a crypto library.)

Thanks.

17. fullstop ◴[] No.40223529{4}[source]
ssh out of the box also does not use libsystemd, except on systems which were patched to do so.
18. pwg ◴[] No.40224950{3}[source]
SSH does not support/use lzma/xz compression method for the SSH protocol.

The xz linkage was indirect through a systemd library that some systemd systems link into sshd.