为什么 systemd/systemctl 是 system v？

Question

不完全是。事实上，旧的 rc.d init 系统可能更容易审计，因为它是用 shell 脚本编写的（编辑：除了 init 守护进程本身，它是用 C 编写的）并且更短。“旧”的 init 系统本身实际上并没有那么安全或不那么不安全本身（编辑：尽管它确实有更多的代码和 dbus 接口 - 有更多的空间出现错误等）。systemd 从一开始就通过将进程放入自己的 cgroup 中来更好地隔离它所管理的进程，但除了稳健地标记进程之外，仅凭这一点本身并没有做太多事情。它可以与以下对话进行比较。

这是一群工人，这是另一群工人。我们把他们分成了小组。他们不能换组。只有主管可以设置你的小组。
好的。但是你还做了其他事吗？
不。
您是否强制执行这样的规则：“组 A 只需要访问这些资源，因此他们只被允许访问这些资源”？
不。
您是否将各个群体与其他群体完全隔离？
不。

像 SysV init、旧的 Arch Linux init 系统（它实际上是建立在 SysV 之上的）、systemd 等，你当然有一些不同的基本配置事物（为了避免具体）自动管理（无论是在启动时启动，还是在任意时间启动x，还是在猪突然学会飞的时候被杀死）。这些事物（systemd 称之为单位）具有某种配置接口（在 systemd 中，类似 INI 的配置文件支持告诉 systemd 使用一些可以提高系统安全性的 Linux 内核功能。以下是摘自的几个例子systemd.exec(5)：

该进程的设备节点白名单和黑名单（DeviceAllow，DeviceDeny）
文件系统命名空间（ReadWriteDirectories、、等）InaccessibleDirectoriesPrivateTmp
拒绝网络访问（的一种用途PrivateNetwork）
拒绝更改 UID ( NoNewPrivileges)
过滤掉特定的系统调用（SystemCallFilter）

以上所有方法都可用于进一步限制由 init 系统生成的进程的行为。您可以根据自己的需要从这些限制中获得一些便利。

到目前为止，我还没有真正看到这些产品的广泛使用，也没有注意到任何认真的努力来用 systemd 将各种服务锁定到最高级别。话虽如此，我不熟悉每个项目的内部情况等，所以请谨慎对待我的话。

Arch Linux 通常尝试使用来自上游源的软件，并尽可能少地进行修改。据我所知，我们不必维护自己的系统，而是决定使用 systemd，因为它似乎将成为事实上（不管是法律上这是有待商榷的问题）标准 init 系统。因此，Arch Linux 维护人员的工作量会减少。

最后要说明的是，Arch Linux 从未使用过 update-rc、chkconfig 或类似的东西。那些是 Debianisms、Fedora/RedHat/CentOS/whateverisms 等。我建议将其从问题中删除。systemctl只是一个进程接口systemd，就像telinitSysV 一样，所以我还建议将其删除。不过，Arch Linux 确实试图用其自主开发的类似 BSD 的 init 系统隐藏 SysV 基础，所以我会保留它。最后，类似“为什么 systemd 要取代 SysV/BSD init？”这样的问题应该更合适。

Answer 1