Live data from Hacker News

Run0, a systemd based alternative to sudo, announced

mastodon.social

91–100 of 902 posts

Re: Run0, a systemd based alternative to sudo, announced

#91
post #79

Why do they have to do this? This is really, really stupid. My issue isn't even that someone tries to replace sudo. That may or may not be a completely fine thing to do, depending on the state of sudo and what improvements can be made. But what makes me really upset is this completely unexplainable need to make everything part of one particular init system. There is absolutely no reason to tie your new sudo replaceme…

Instead of just hating based on assumptions it would be useful to actually familiarize with the thing you are critizising > But what makes me really upset is this completely unexplainable need to make everything part of one particular init system systemd is not init system, its and umbrella project for various core system components, which includes an init system. > There is absolutely no reason to tie your new sudo…

> systemd is not init system, its and umbrella project for various core system components, which includes an init system.

The point being made is that it directly depends on the init system part.

> well, in this case there is good reason to have it interact with service manager in general

I disagree! There's no reason to not have it be its own daemon with its own configuration and looser bindings to the rest of the systemd ecosystem (e.g. through dbus and other protocols). KDE applications do this a lot, where they take advantage of other KDE components if present. This is strictly a philosophy thing and not a requirement for achieving what he proposes.

> their "portable and stable" APIs

"we're portable if you reimplement our APIs", idk how this is an argument. They consistently make very little effort to be compatible with (or provide fallbacks for) what's already there. Having stable APIs is nice but there's a reason most of the interfaces on that page don't have alternative implementations: They solve questionable problems and provide no tangible benefits over the methods there were before. Yet projects feel compelled to hard-depend on them...

> The couplings between systemd projects are not that tight, you can pick and choose which parts you want, they explicitly are not "forcing all their projects" to consumers.

In practice they are. The primary reason why everything is shipped as a single project is because that makes it easier to make available in different distros (they just enable everything), allowing it to become the "de facto" standard since it's available everywhere. There's a lot of projects that solve some of the systemd tools' in sometimes better ways, that never see the light of day because they don't have a trojan horse to ride in with.

There's a reason why projects like elogind exist, because there's only a very select few systemd tools that work without systemd at all

Re: Run0, a systemd based alternative to sudo, announced

#92
post #56

Earlier quoted context omitted.

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

[flagged]

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.

Re: Run0, a systemd based alternative to sudo, announced

#93
post #59

Earlier quoted context omitted.

Is that really how they develop software? Because I'm pretty sure that most of the components are optional. You did not even discuss the reasoning given for not using sudo to instead hop on your soapbox to say it's bad software with bad practices and that they are stupid. It's annoying how in the the more surface level Linux communities there's 0 value in discussing systemd. "1 million lines of code for PID0!" The ne…

Why are you bringing up random arguments I didn't even make? No, I am a dedicated systemd hater ever since I spend over a month full time writing and debugging systemd services for work. Systemd (the init system) is just all around badly designed and executed, I have very little confidence in the developers and their technical abilities and their tendencies to expand into completely unrelated areas for seemingly no r…

Because your post is the repeating cliches that are under every discussion about systemd.

You're essentially saying that the month you spent is enough for you to call it bad and the creators incompetent.

What qualifies you to make a determination like that?

There is never any actual technical reasons it's always about vague things like not adhering to UNIX philosophy, lines of code or it being badly designed (without any real architectural criticism)

This is an article about why they believe sudo isn't a good system. Where's your criticism of that from a technical / security perspective?

It's been about 10 years since systemd was adopted by Debian/Ubuntu/Redhat/Fedora etc.

Millions of deployments over the years. The companies that build and are paid to support for years with SLAs the operating systems are using it without issue.

Re: Run0, a systemd based alternative to sudo, announced

#94

Just a reminder that there are plenty of systemd-less distros available. Also a reminder that those distros would have been safe from the nearly-solar-winds-level backdooring of Linux distros from XZ utils.

That backdoor was never pushed out of the testing branches for distros.

Re: Run0, a systemd based alternative to sudo, announced

#96
post #93

Earlier quoted context omitted.

Why are you bringing up random arguments I didn't even make? No, I am a dedicated systemd hater ever since I spend over a month full time writing and debugging systemd services for work. Systemd (the init system) is just all around badly designed and executed, I have very little confidence in the developers and their technical abilities and their tendencies to expand into completely unrelated areas for seemingly no r…

Because your post is the repeating cliches that are under every discussion about systemd. You're essentially saying that the month you spent is enough for you to call it bad and the creators incompetent. What qualifies you to make a determination like that? There is never any actual technical reasons it's always about vague things like not adhering to UNIX philosophy, lines of code or it being badly designed (without…

>There is never any actual technical reasons it's always about vague things like not adhering to UNIX philosophy, lines of code or it being badly designed (without any real architectural criticism)

I did not mention the first two, so please do not pretend I argued that. For bad design look at transactions. That is really dumb and makes the system near incomprehensible. The documentation is bad, dbus is literally so bad they tell you not to use it without a wrapper. The terminology is very questionable and makes it hard to explain what a unit actually does.

But I don't even see that as the worst part. The worst part is that they fundamentally can't do basic software engineering, in the sense that they do not have a defined project scope. Everything is potentially a systemd issue and not once does anyone take a step back and say "maybe systemd" isn't the right place to fix that problem.

>This is an article about why they believe sudo isn't a good system. Where's your criticism of that from a technical / security perspective?

If you don't read my posts please do not respond to me. Look at the first post I made and carefully read it.

Re: Run0, a systemd based alternative to sudo, announced

#97

Earlier quoted context omitted.

Riddle me this: can I create new mount files inside a systemd unit and have them activated to mount the locations specified? Do I need a daemon reload, for this?

That sounds like a job for systemd.generator. I don't think having an unit that generates units at runtime is an officially supported use case, since generators exist.

This doesn't answer the question. Also generators are started very early, before other units have been started, so if your system is already running and now you want to generate those units, depending on the state of the other units, they don't really help.

>I don't think having an unit that generates units at runtime is an officially supported use case

Are you sure? Can you tell me how I would find out?

Re: Run0, a systemd based alternative to sudo, announced

#98
post #87

Earlier quoted context omitted.

Both can be true though, it can create an integrated system where everything systemd-* works together, but where you can replace any systemd-* you don’t like with something else

The point of an integrated system is that interactions between components enhance the system as a whole. This is obviously incompatible with an easy replacement of components. This is literally just basic systems engineering. I don't even know what you are arguing here. The more tightly integrated a system is the harder it is to replace individual components.

You can have a well-integrated system without having tight coupling between components. Interfaces are a thing, and a high level of integration just means having a good collection of interfaces between well-defined conceptual components with well-defined capabilities. The actual software that implements those components is entirely separate.

Re: Run0, a systemd based alternative to sudo, announced

#99

Earlier quoted context omitted.

It either has to be SUID or it has be a daemon running as root (or with enough caps to make the difference not matter). Adding a needlessly verbose configuration ecosystem doesn't change that. I imagine there's going to be some cool stuff this can do with homed and userctl, but it's not like the fundamental problem of "this program can grant root privileges" can ever go away.

The problem is not "this program can grant root privileges", it's that the setuid bit sucks. Linux processes inherit a lot of state from the parent which means it's absolute hell to make a secure setuid binary. And at any time the Linux kernel can add a new feature which will be inherited by a child process, but that the process can't defend against because it wasn't even a thing when the code was written. Running a…

Sure, but your choices are running an on-demand binary suid root, or running a persistent daemon as root.

Both have problems, but if you're going to switch users to root you have to do one of them.

Re: Run0, a systemd based alternative to sudo, announced

#100
post #94

Just a reminder that there are plenty of systemd-less distros available. Also a reminder that those distros would have been safe from the nearly-solar-winds-level backdooring of Linux distros from XZ utils.

That backdoor was never pushed out of the testing branches for distros.

Not sure of the relevance of this comment, can you elaborate? Were you the one that caught it? Our balls were inches from the bandsaw. Systemd made it possible to compromise SSH through an unrelated, single-maintainer lib that wasn’t even a dependency.

Edit: never mind, I see you are a systemd crusader.

Post reply on HN