0xC*_*22L 8 security chroot root webserver capabilities
考虑到未来的 Web 服务器设置，我突然想到，出于某种原因，Web 服务器通常以 root 身份启动，然后放弃setuid工作进程的某些权限 ( )。此外，经常chroot涉及，这并不完全意味着作为一种安全措施。
我想知道的是，为什么 Web 服务器（我已经管理了从 Apache、lighttpd 到 nginx 的所有内容）不使用功能系统 ( capabilities(7))，例如CAP_NET_BIND_SERVICE在 Linux 上以非 root 用户身份启动？...这种方式仍在侦听低于 1024 的特权端口。
或者更好，我认为他们中的大多数人都可以，但为什么这不是普遍做法？为什么不 ...
setcap(8)with CAP_NET_BIND_SERVICE？chroot帮助，请使用chroot或lxc“监禁”网络服务器？除了（工人）子进程可能会杀死我可以想出的父进程之外，没有什么比直接开始作为root.
那么，为什么他们传统上以 root 身份启动，然后一切都已完成以消除随之而来的隐含安全问题？
尽管 POSIX 有一个我认为包括 CAP_NET_BIND_SERVICE 的功能标准，但这些不是一致性所必需的，并且在某些方面可能与例如 linux 上的实现不兼容。
由于像 apache 这样的网络服务器不是只为一个平台编写的，因此使用 root 权限是最便携的方法。我想它可以专门在 linux 和 BSD（或检测到支持的任何地方）上执行此操作，但这意味着行为会因平台而异，等等。
在我看来，你可以配置你的系统，这样任何网络服务器都可以这样使用；这里有一些关于这个 WRT apache 的（也许是笨拙的）建议：NonRootPortBinding。
那么，为什么他们传统上以 root 身份启动，然后一切都已完成以消除随之而来的隐含安全问题？
他们以 root 身份启动，因为他们通常需要访问特权端口，而传统上这是唯一的方法。他们后来降级的原因是因为他们随后不需要特权，并且限制了服务器常用的无数第三方附加软件带来的潜在损害。
这并非不合理，因为特权活动非常有限，并且按照惯例，许多其他系统守护程序连续运行 root，包括其他 inet 守护程序（例如，sshd）。
请记住，如果服务器被打包以便它可以作为具有 CAP_NET_BIND_SERVICE 的非特权用户运行，这将允许任何非特权用户启动 HTTP(S) 服务，这可能是更大的风险。