3 ms·
> 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.
by deng 2y ago
> 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.
- constantcrying 2y ago>Systemd already handles logins Exactly that was my objection.
- deng 2y agoAnd 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.
- cryptonector 2y agoI 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
- deng 2y ago> 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?
- Spivak 2y agoPeople who just have an axe to grind with systemd really don't like when you point out that it's incredibly modular and follows the unix philosophy. I think what people mean to say but don't have the words for is that systemd is an East coast school of thought project and folks prefer "worse is better" style tools.
- cryptonector 2y agoI like the idea behind systemd. I don't have an axe to grind. I don't want SysV init or whatever you might think.
- cryptonector 2y ago> 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.
- deng 2y ago