Most active commenters
  • growse(3)

←back to thread

Run0, a systemd based alternative to sudo, announced

(mastodon.social)
466 points CoolCold | 31 comments | 29 Apr 24 23:59 UTC | HN request time: 0.841s | source | bottom
Show context
kbar13 ◴[30 Apr 24 07:38 UTC] 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 #
1. Faaak ◴[30 Apr 24 07:49 UTC] 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 #
2. throwaway598 ◴[30 Apr 24 08:48 UTC] No.40208645[source]▶
The root of the problem is sudo, and su more generally. This derives from *nix, or mainstream versions today, requiring a super user, a manifestation of the problem with monolithic kernals. A microkernal may be a stepping stone to improving this but even this is not a solution. The only solution is no kernal space, no privileged user(s), all processes negotiate independently with each other.
replies(1): >>40215326 #
3. dale_glass ◴[30 Apr 24 08:58 UTC] No.40208710[source]▶
systemd isn't a single piece of software. It's a collection of software with an unified theme, like KDE or Gnome.

Attack surface-wise, I don't think there's much difference between "sudo" being a part of the systemd package and not. Either way there's "sudo" code to be targeted, which package it's part of is just a technicality.

replies(1): >>40211011 #
4. growse ◴[30 Apr 24 09:46 UTC] No.40209034[source]▶
I think dynamic linking pre-dates systemd by quite a number of years.
replies(1): >>40209169 #
5. StimDeck ◴[30 Apr 24 10:08 UTC] No.40209169{3}[source]▶
SSH being linked to XZ doesn’t.
replies(3): >>40209743 #>>40214774 #>>40214989 #
6. growse ◴[30 Apr 24 11:19 UTC] No.40209743{4}[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 #
7. SAI_Peregrinus ◴[30 Apr 24 13:57 UTC] No.40211011{3}[source]▶
I like to compare Systemd to GNU. Pretty similar scale, similar "take over the world" levels of adoption in Linux (GNU's libc is in nearly everything, all the other GNU tools are ridiculously common), adds lots of attack surface to what used to be single-purpose simple tools, etc. Just about every criticism of Systemd applies just as well to GNU.
replies(2): >>40215317 #>>40216650 #
8. jacoblambda ◴[30 Apr 24 16:19 UTC] No.40212740[source]▶
The issue is that it's not just ideological. "Do one thing and do it well" is important because if you want to port software to another platform, it's a lot easier to port a single dependency component over to make it work than it is to port over the entire framework.

This is a serious problem and it makes it way harder to make things cross platform.

replies(1): >>40215134 #
9. SR2Z ◴[30 Apr 24 18:55 UTC] No.40214774{4}[source]▶
Why wouldn't SSH be linked to XZ? Isn't it supported as a compression method for connections?
replies(2): >>40215048 #>>40224950 #
10. tommiegannert ◴[30 Apr 24 19:11 UTC] No.40214989{4}[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 #
11. yjftsjthsd-h ◴[30 Apr 24 19:16 UTC] No.40215048{5}[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 #
12. ◴[30 Apr 24 19:21 UTC] No.40215111{5}[source]▶
13. immibis ◴[30 Apr 24 19:21 UTC] No.40215112{5}[source]▶
"Put everything in one big ball" is systemd mentality AND something that enabled the xz exploit to work.
replies(1): >>40216864 #
14. Xylakant ◴[30 Apr 24 19:23 UTC] No.40215134[source]▶
Systemd was written specifically for Linux, hard depends on a list of features provided by the Linux kernel and leverages them to do its work. Porting it to another kernel is a rewrite. Lack of portability is in this case a design tradeoff.
replies(2): >>40215607 #>>40215608 #
15. ◴[30 Apr 24 19:37 UTC] No.40215317{4}[source]▶
16. metalforever ◴[30 Apr 24 19:38 UTC] No.40215326{3}[source]▶
No the root of the problem is the large attack surface systemd is creating by tightly coupling a ton of tools together, I agree about the microkernel idea completely though.
17. jacoblambda ◴[30 Apr 24 20:00 UTC] No.40215607{3}[source]▶
Sure that is the case for systemd itself but it's not the case for most projects that happen to use things systemd provides.

There is very little benefit for most userspace software to tie itself to systemd and by extension linux when otherwise it could be portable to any unix or unix like platform. Especially when an alternative, portable solution already exists and is well established.

18. fhars ◴[30 Apr 24 20:00 UTC] No.40215608{3}[source]▶
The argument was that this design of systemd makes it hard to write applications that are portable, so that systemd is effectively a very big net negative to the open source ecosystem, because it causes massive fragmentation.
19. michaelmrose ◴[30 Apr 24 20:06 UTC] No.40215680{5}[source]▶
In void it links 11 and includes only libz of the items you listed.
20. fsflover ◴[30 Apr 24 21:34 UTC] No.40216650{4}[source]▶
https://news.ycombinator.com/item?id=40215413
21. growse ◴[30 Apr 24 21:53 UTC] No.40216864{6}[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 #
22. riddley ◴[30 Apr 24 22:08 UTC] No.40217025{6}[source]▶
xz is a compression library.
replies(1): >>40217925 #
23. immibis ◴[30 Apr 24 22:42 UTC] No.40217338{7}[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?
24. yjftsjthsd-h ◴[30 Apr 24 23:55 UTC] No.40217925{7}[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.
25. dijit ◴[01 May 24 00:12 UTC] No.40218038[source]▶
I think this is a really old statement. I’ve used systemd since it was made default in Fedora back in 2011 (Lovelock, anyone?) - at what point am I qualified to have an opinion, after having used it personally for 13 years and professionally for 8.

systemd is scary for 3 reasons.

1. it is inscrutable. Debugging it is nearly impossible, so you had better hope you don’t get a buggy release, especially with how hostile the devs can be.

2. it is large, and growing. Lots of things it claims are optional are in reality: not really. This is fine until uou get something that really doesnt work well (systemd-resolved is consistently the largest reason I have connectivity issues, wether it be because it interferes with docker inter-container networking or because it needs to time-out when trying DNSSec to continue- or if it fights with my vpn provider for power over my resolvers etc). Due to my distro being very tied to it: I gotta keep using it and working around it.

3. The interface is irreplaceable. Why are their 13 init systems? Because init is a closed scope. To be a sucessful init you need to spawn processes and do it cheaply. Supervising processes after start? Noble, and there were implementations that could do that (CDDL licensed SMF from Solaris for example). However we have already reached the state where it will be literal man-decades of work to replace systemd as we will need to make any replacement bug compatible with systemd itself. Its the ultimate show stopper.

The implementation is the reference. Which is a large departure now from what came before.

26. t-3 ◴[01 May 24 00:58 UTC] No.40218362{5}[source]▶
On OpenBSD it links 4 libraries. On my crux linux installation, 7.
27. _flux ◴[01 May 24 07:22 UTC] No.40220443[source]▶
They didn't need to use the library to make use of the systemd notify mechanism, which is simple to interface and quite a nice feature in the first place.

The free-standing implementation: https://github.com/openssh/openssh-portable/commit/08f579231...

28. jwilk ◴[01 May 24 07:33 UTC] No.40220509{5}[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 #
29. tommiegannert ◴[01 May 24 07:56 UTC] No.40220650{6}[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.

30. fullstop ◴[01 May 24 14:14 UTC] No.40223529{6}[source]▶
ssh out of the box also does not use libsystemd, except on systems which were patched to do so.
31. pwg ◴[01 May 24 15:48 UTC] No.40224950{5}[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.