Live data from Hacker News

Run0, a systemd based alternative to sudo, announced

mastodon.social

741–750 of 902 posts

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

#741

> Or in other words: the target command is invoked in an isolated exec context, freshly forked off PID 1, without inheriting any context from the client (well, admittedly, we do propagate $TERM, but that's an explicit exception, i.e. allowlist rather than denylist). I think in practice, this is going to be an endless source of problems, so much so that it won't be adopted. The usual use case of sudo is that you have…

run0 has already been exploited: https://twitter.com/hackerfantastic/status/17854955875146385...

There will be plenty more where that came from. Yet another terrible idea and terrible implementation from Poettering.

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

#742
post #230

Earlier quoted context omitted.

> remember when you had to write bash scripts to start, stop, restart services This was a really big pain, yes, but I also remember how I could `tail -f *.logs`. I remember how I didn't need to remember about `--no-pager` and `--follow`. I knew where the files were, what they were called. I remember how I didn't have to google how to find logs between 10 days ago and 4 days ago, because the logs would be in a .tar cr…

> I could `tail -f *.logs`. I remember how I didn't need to remember about `--no-pager` and `--follow`. journalctl supports -f, which by your own account you were already using for tail, so I'm not clear what's worse there. > I remember how I didn't have to google how to find logs between 10 days ago and 4 days ago, because the logs would be in a .tar created by logrotate with a date in the filename. My memory of thi…

This and many other discussions misses the point that most people that don't like systemd have with it.

It can largely do everything it replaces, but differently, in some cases with improvements. Every year it increases its scope of 'problems' its solved.

But the issue is it hasn't _ACTUALLY_ solved a problem for me in about a decade, its only introduced problems. Its replaced things that worked perfectly for me and millions of other users for years/decades with something that... also works... but differently. Now to accomplish the _SAME_ outcome without any personal benefit I have to re-learn their new and usually opinionated way.

There was a time I could log into a system, find logs, parse dates and do everything in these discussions reletave to logs, rotation. Regardless of service because the standards were close enough and the basic tooling (tail/find/tar/grep/awk etc.) worked everywhere always, and you never had to google even if the service was one you never worked on before.

For systemd its the opposite, its almost a guarantee you have to google something along the line when interacting with new systems and services. And as soon as their newly enforced opinions and way of doing things is getting comfortable they go and replace something else that was also working... perfectly fine.

If it actively solved problems for the majority of users we wouldn't hate it so much. Instead it requires more mental overhead than anything other than XORG to deal with and constantly manage than anything else in the linux ecosystem.

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

#743

Earlier quoted context omitted.

> Just one example: https://github.com/systemd/systemd/issues/6237#issuecomment- ... 1. He gave a clear reason why it is how it is 2. He realizes it is/might be frustrating 3. even `adduser` will not allow it by default 4. The issue that it still runs the unit even with config errors has been addressed: https://github.com/systemd/systemd/commit/bb28e68477a3a39796... (~2 weeks after the issue was opened)

His reason, although clear, is also plainly wrong. Such usernames although bizarre may be encountered by SystemD so it shouldn't break when it sees them. Computer programs, particularly important ones, should be conservative in what they emit and liberal with what they accept and that means not breaking when they encounter weird but technically permissible usernames. His response should have been "Golly, that's a wei…

There is a certain personality type that likes to reimagine that their original thinking was not flawed, even when presented with a detail that they did not incorporate into their original thinking. If the detail had been in their awareness from the start, they would have arrived at a different position, but they are bound to a strict sense of linearity for reasons inexplicable to me except for ego protection.

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

#745

Earlier quoted context omitted.

My last job was at a UK bank. All our *nix systems were configured with a specific whitelist of commands that could be run via sudo. We found this an enormous pain in the arse when the powers that be decided to deploy ansible everywhere, and found that none of its "become" methods would work if sudo was set up like that.

I had a job once which had a sudo whitelist, but vi was included. !sh and you had root.

[deleted]

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

#746

Earlier quoted context omitted.

> And I'm kind of worried that when this breaks stuff, the systemd project is going to push forward with some plan to get rid of sudo, and not gracefully accept the feedback that this is breaking things. Given Lennart already declared SUID concept as “bad”, I think this is the game plan all along. Systemd: Do all the things, but not very well, and don’t listen to anyone.

I agree with Lennart so I'm curious what the argument is against the notion that SUID was a bad idea and we should move away from it in Linux?

The problem with this line of thinking is it gives automatic carte blanche to anyone pointing out problems to implement "solutions" to those problems with little interrogation of whether those solutions are actually better.

SUID, like any system, is flawed. Most of those flaws are balanced trade-offs; if you're addressing one you need to be aware of the severity of any counter-problems you're inevitably introducing.

Lennart is well known for criticising existing systems while simultaneously ignoring & dismissing criticism of the proposed solutions - you need to be able to weigh up both sides in a balanced way. Lennart demonstrably isn't.

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

#747
post #741

> Or in other words: the target command is invoked in an isolated exec context, freshly forked off PID 1, without inheriting any context from the client (well, admittedly, we do propagate $TERM, but that's an explicit exception, i.e. allowlist rather than denylist). I think in practice, this is going to be an endless source of problems, so much so that it won't be adopted. The usual use case of sudo is that you have…

run0 has already been exploited: https://twitter.com/hackerfantastic/status/17854955875146385... There will be plenty more where that came from. Yet another terrible idea and terrible implementation from Poettering.

Huh. I'm not at all a fan of how Poettering operates, but it's neither the ideas nor the implementation where I'd fault him. Well, it depends on what you mean by implementation, I guess; I'm talking about the core "how does it do its thing", not the interface by which you use it.

I think Poettering has great ideas and great implementation. It's the execution and interface that are often terrible. If the square peg doesn't fit in the round hole, then he'll always say that the peg is perfect and the world just needs to chisel out the corners of the hole.

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

#749

Earlier quoted context omitted.

I agree with Lennart so I'm curious what the argument is against the notion that SUID was a bad idea and we should move away from it in Linux?

SUID mechanism doesn’t always “elevate to root”. It’s a mechanism to “run as another user” and with SGID allows great flexibility in user permission management. You can allow all kinds of (responsible) user switch tricks for multi-admin servers and multi-user systems. Focusing all of this to sudo and framing SUID as “just implemented to enable sudo” is not painting the correct picture. Moreover, removing SUID breaks…

All these ideas that tie permissions to a file completely fail when files need to be accessed either over network, or inside a container.

I can see how the original authors didn't consider these cases, because they simply weren't there yet... but knowing what we know today: SUID is an awful idea.

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

#750
post #469

Earlier quoted context omitted.

> The popularity of systemd encourages people to require it, which is the major problem The usefulness of systemd encourages people to require it. Projects most often require it in cases where either there isn't an alternative, the alternative isn't maintained, or the alternative is missing functionality.

Self perpetuating growth. Systemd integrates many functions so people default using it and add even more functionality that bring even more people into ecosystem. Which is basically how every tech ecosystem works. The problem is that linux is supposed to not be just_another_centrally_controlled_ecosystem, so when systemd abuses their popularity by enforcing whole ecosystem (rather then cut itself into separate pieces…

It seems like you're attributing to perceived malice ("enforcing") what is better explained by a combination of trying to get things done and not prioritizing replaceability higher than the benefits of integration. In other words, a project that simply has different priorities.

It turns out that many other people also like seeing stuff get done more so than they care whether the project in question is trivially replaceable.

Post reply on HN