←back to thread

466 points CoolCold | 2 comments | | HN request time: 0.015s | source
Show context
constantcrying ◴[] No.40208131[source]
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 replacement to systemd. Absolutely none.

This is a completely insane way to develop software, instead of creating a new piece of software in a separate project they will force all their projects simultaneously onto all their users for absolutely no reason.

I am very glad to have jumped ship from systemd. It is particularly bad software created by a team of people who engage in very bad practices and a totally unhealthy view of software in general.

replies(15): >>40208192 #>>40208204 #>>40208221 #>>40208253 #>>40208266 #>>40208277 #>>40208280 #>>40208283 #>>40208314 #>>40208386 #>>40208516 #>>40209218 #>>40215207 #>>40215247 #>>40215377 #
deng ◴[] No.40208277[source]
> But what makes me really upset is this completely unexplainable need to make everything part of one particular init system.

It is not unexplainable at all. In fact, the article explains it very well.

sudo allows you to execute code as another user. If you think about it, you could also replace sudo with ssh to localhost - just set a root password and allow root logins. Now, security-wise, this would obviously be a bad idea. Our current solution is to give the sudo binary itself administrative privileges, which is a slightly less bad idea, but still pretty bad.

Systemd already handles logins, so it is quite obvious that it could also handle this problem very well, and in fact, it already does: there is a tool systemd-run which you can already use. It will create a completely new process and will handle communication to it, just like ssh, but without the above downsides.

replies(1): >>40208464 #
constantcrying ◴[] No.40208464[source]
>Systemd already handles logins

Exactly that was my objection.

replies(1): >>40209033 #
deng ◴[] No.40209033[source]
And I disagree with that. The 'sudo problem' is a good example why it makes sense to handle init and login by the same system (note I'm not meaning "same binary" here, in fact, they are separate binaries in systemd). The SUID approach for sudo has been a problem for decades, and it needs to go. I don't really care if it's done by systemd, or if we agree on another system like S6 that was mentioned in another thread - in the end, they work very similarly be replacing the old sudo with an IPC approach.
replies(1): >>40215246 #
cryptonector ◴[] No.40215246[source]
I agree with u/constantcrying. This should not be part of systemd. It should be a separate service [started by systemd].

Reasons:

- systemd is a large beast -- no need to make it larger with unrelated things

- the Unix philosophy seems to be applicable here

- the result should be portable to non-systemd systems

replies(1): >>40220922 #
deng ◴[] No.40220922{3}[source]
> systemd is a large beast -- no need to make it larger with unrelated things

I think I sufficiently explained why it is very much related.

> the Unix philosophy seems to be applicable here

Systemd very much follows the unix philosophy. It is not one big binary, but actually consists of dozens and dozens of tools communicating with each other through protocols.

> the result should be portable to non-systemd systems

Portable on what basis? POSIX?

replies(2): >>40222509 #>>40224179 #
1. cryptonector ◴[] No.40224179{4}[source]
> I think I sufficiently explained why it is very much related.

This:

| Systemd already handles logins

?

But I don't see why a bring-up/shutdown system should handle logins.

> Systemd very much follows the unix philosophy. It is not one big binary, but actually consists of dozens and dozens of tools communicating with each other through protocols.

That is fine. As long as this service (sudo replacement) is a standalone, separate daemon started by a systemd unit, I'm happy. If it's a core part of systemd itself then I'm not happy.

> Portable on what basis? POSIX?

Or Linux / glibc / musl, sure, why not. Some people (no, not me) want to run Linux w/o systemd. The point is that a sudo replacement service should be fairly portable to the universe of UNIX/Unix/BSD/Linux.

replies(1): >>40233231 #
2. deng ◴[] No.40233231[source]
> Or Linux / glibc / musl, sure, why not. Some people (no, not me) want to run Linux w/o systemd. The point is that a sudo replacement service should be fairly portable to the universe of UNIX/Unix/BSD/Linux.

This fetish of "everything should just stick with libc and POSIX" needs to go. These standards have not evolved at all, they are decades behind and don't even remotely cover the necessary requirements for implementing a "sudo replacement service". Just stick with sudo then.