Run0, a systemd based alternative to sudo, announced

> There are system-d haters, sure.

> ...but system-d apologists are also a thing.

Why do you feel the need to insert this personal insult into an otherwise impersonal argument? This infuriates me. I'm not sitting here inflamed with passion to argue about systemd because I think it is great. I'm sitting here arguing about systemd because I feel someone was wrong on the Internet.

https://xkcd.com/386/

If you want to ascribe me as some "systemd apologist" because I am willing to "defend" systemd when I feel it is justified, then so be it, but it's wildly inaccurate, and framing it this way is biased in and of itself. It implies some kind of personal identification with things like init systems that I don't have. I have strong opinions, but I have those about everything.

> There's a fairly comprehensive thread about this (1), and my take away from it was not 'this had nothing to do with systemd'.

That's an enormous thread, if it really has a substantive bit can you please at least point to it? There's no chance I'm reading another thread about the xz incident.

> You can argue where blame lies for it,

Which is what I did do

> but that it involved system-d, and would not have been possible without system-d is not in dispute.

FWIW it would have been possible to backdoor Linux via liblzma5 without sshd linking to it. The actual thing that makes the sshd backdoor so incredibly stealthy is a combination of the fact that it is done in such a roundabout way (through an unexpected dependency), in a way that it would only be activated by downstream patches in distros and not upstream code. That last part is really nifty for avoiding detection.

There are still plenty of places where liblzma5 is used, with root privileges even. For example, many package managers use liblzma5. It certainly would've been possible to install a backdoor into sshd through that vector.

People are reading a bit much into the systemd link, but even if you won't accept that backdooring Linux would've been completely doable through liblzma5 without systemd, I would still contend that linking to liblzma5 is honestly a completely reasonable thing for a system library to do; heck, sshd itself already links to zlib. While 0 unused dependencies are better than 1, the picture people paint is that systemd recklessly linked in a bunch of libraries which is the only possible way a compromise of the xz project could've backdoored Linux, but the reality is a lot more nuanced than that.

> You're stepping from 'lets argue about system-d being big and clunky' into 'nothing is ever wrong with system-d we cannot tolerate critique!' here.

That's neither where this argument started nor where it is. Nothing in my single reply in this thread even remotely suggests the latter. It is a direct confrontation of two specific points.

> ...but, come on. We're arguing about the minute (irrelevant) details of a much larger point being made here.

> System-d is a big complex system; it is kind of funny that something that is big and complex

sigh. Now we're all the way back to square one. systemd is not a monolithic piece of software, it is a suite of programs.

> and part (undenyably) of a major recent security scare is part of the plan to replace sudo to be more secure and less complex.

I don't see this as funny at all considering that you don't need a bunch of roundabout logic to find security issues in sudo, they happen fairly regularly.

https://www.sudo.ws/security/advisories/

> I believe the intent is good, and the result will probably be better than the mess that sudo is now; but that's because sudo is a mess (or I personally think so anyway), not because system-d is simple, or easy, or somehow fundamentally more secure.

> If you can't see the irony here, you are dancing around with your hands over you ears.

Well, trust me when I say this, but I can tell you right now that I am witnessing a lot of irony.

Yes you need a daemon reload to discover the new unit files. Is there in issue with doing this? A reload means reread its config, it's not a reexec.

Its a common finding during pentests, but that's just unconvincing anecdote vs. anecdote. Another argument, besides misconfiguration, is the reduced attack surface by removing the huge complexity of sudo entirely. If your argument is basically that its fine because nobody is using the complexity of sudo, then I don't quite understand what your objection is to removing that complexity. You might need to manually restore some env-vars, whats the big deal?

But I suspect this would just turn into a "doing things differently is bad because its doing things differently" argument, its not a very useful conversation to have.

Then I propose letting systemd hijack sudo's usefulness only on server installs.

Dang. I wish I had the autism to bristle at colors. Think about all the lost hours agonizing over themes! Not feeling the agonizing tension between the fact that cool-retro-term made your terminal into an awesome monochrome CRT but that it's monochrome green so your syntax highlighting is all messed up!

> back when I used linux

What do you use now? :0 BSD? Plan 9???