So does sysvinit. PID 1 has to be root to do its job. Under sysvinit it is the responsibility of each daemon to drop privileges on their own if they wish to do so.
Systemd can handle your services such that they start unprivileged from the get go. It also offers a lot of isolation by default with options like PrivateTmp, ProtectHome, ProtectSystem powered by cgroups. It can effectively run your services like they’re in a Docker container if you want.
A lot of systemd also runs as separate services with their own user as well. Only the core init part really runs as root, it prefers to drop privilges and apply cgroup isolation wherever it makes sense to do so. The logger for example runs as systemd-journald, the DNS resolver runs as systemd-resolved. They’re part of the systemd package but far from all of it runs as root. Systemd can even do certain privileged operations so that the service can run with less privileges such as binding port 80/443 for you so the web server doesn’t need root at all to run.
It also enables users to do certain operations without requiring elevating privileges with sudo, which in many cases can help not have to give sudo NOPASSWD specific commands because your web developers need to be able to restart the web server, you can just add a Polkit rule that allows restarting that service without privileges. Systemd is all D-Bus, so you can control access at a very granular level. You can grant only start and reload if you want.
Sysvinit is just shell scripts running as root. There is no security whatsoever, it was never sysvinit’s job to secure the system. It’s mostly fine as all the tooling for it also requires root to use. But it does require root 100% of the time to interact with it.
There’s good reasons to prefer sysvinit, those are just common FUD systemd haters keep spreading. There’s no need to discredit or outright lie about systemd to justify preferring sysvinit: the simplicity of a few shell scripts and not needing 99% of what systemd does is a perfectly valid argument on its own.
I have boxes that use systemd very heavily and some that have a custom bash script as the init because the box only needs an IP and to start a single app. Right tool for the right job and stuff.
More Code in Kernel-space = less secure
Systemd = a lot of Code in Kernel-space
There’s no kernel-space code in systemd.
Right, sorry, i just watched a documentary about anti-cheat.
But it still runs with elevated peivileges, which i don’t really like
So does sysvinit. PID 1 has to be root to do its job. Under sysvinit it is the responsibility of each daemon to drop privileges on their own if they wish to do so.
Systemd can handle your services such that they start unprivileged from the get go. It also offers a lot of isolation by default with options like PrivateTmp, ProtectHome, ProtectSystem powered by cgroups. It can effectively run your services like they’re in a Docker container if you want.
A lot of systemd also runs as separate services with their own user as well. Only the core init part really runs as root, it prefers to drop privilges and apply cgroup isolation wherever it makes sense to do so. The logger for example runs as systemd-journald, the DNS resolver runs as systemd-resolved. They’re part of the systemd package but far from all of it runs as root. Systemd can even do certain privileged operations so that the service can run with less privileges such as binding port 80/443 for you so the web server doesn’t need root at all to run.
It also enables users to do certain operations without requiring elevating privileges with sudo, which in many cases can help not have to give sudo NOPASSWD specific commands because your web developers need to be able to restart the web server, you can just add a Polkit rule that allows restarting that service without privileges. Systemd is all D-Bus, so you can control access at a very granular level. You can grant only start and reload if you want.
Sysvinit is just shell scripts running as root. There is no security whatsoever, it was never sysvinit’s job to secure the system. It’s mostly fine as all the tooling for it also requires root to use. But it does require root 100% of the time to interact with it.
There’s good reasons to prefer sysvinit, those are just common FUD systemd haters keep spreading. There’s no need to discredit or outright lie about systemd to justify preferring sysvinit: the simplicity of a few shell scripts and not needing 99% of what systemd does is a perfectly valid argument on its own.
I have boxes that use systemd very heavily and some that have a custom bash script as the init because the box only needs an IP and to start a single app. Right tool for the right job and stuff.
Right, same problem with the desktop “OS Wars”, I just don’t see the point. Personally, on any given day, I’m switching between all 3 major OS’s
eBPF: psst, wanna run your code directly in kernel?