以 root 身份运行 Unicorn 这样的 Web 服务器是否存在安全风险？
Nginx 主进程以 root 身份运行，Nginx 工作进程以有限的 www-data 用户身份运行，但我无法设置像 www-data 这样的另一个用户来运行 Unicorn master/workers，而不弄乱 www-data 的PATH.
答案1
以 root 身份运行 Unicorn 这样的 Web 服务器是否存在安全风险？
正如托马斯在 sec.se 聊天中所说，跑步任何事物因为 root 存在隐含的安全风险。关于 root 需要了解的一点是，内核本质上信任它的所有行为，而不会抱怨。
如果 nginx 或 unicorn 中存在任何漏洞，就会出现此问题。如果发生这种情况，则可能可能会执行漏洞利用，滥用进程。
然而，了解这些服务器的工作原理对于了解漏洞利用向量可能是什么非常重要。理论上，持有 root 权限必须执行两个部分 - 读取配置和bind()操作（假设您的服务器的端口 < 1023）。
unicorn 充当预分叉模型（假设gunicorn 类似）——每个客户端请求都在单独的进程中处理。以 root 身份运行的进程的工作是绑定到必要的端口，然后将连接传递给工作进程。 Worker 模型混合了线程和进程。据我了解，nginx 以非常相似的方式运行，但它对异步 IO 有更大的偏见 - 我相信epoll// kqueue。accept如果你看一下解决c10k问题的策略这就是设计以这种方式运作的原因。
从理论上讲，大多数工作进程可以seteuid()并且seteguid()应该放弃其根权限。当这些进程不以 root 身份处理所有流量时，就会出现问题；大多数进程确实会放弃其 root 权限。我还应该做两个相当明显的声明：
- 如果您不绑定到 < 1024 的端口，您可以将 nginx 守护进程配置为以 root 以外的身份运行。
- 在我的例子中，您可以（我也这样做）配置 unicorn (gunicorn) 来创建套接字文件，这意味着它不需要以 root 身份运行。 nginx 可以将 Web 请求代理到 unix 套接字上，这意味着gunicorn 永远不会公开 tcp 连接。
代码的“脆弱部分”应该因此相当于解析配置文件并切换连接；理论上因此，假设该方法有效并且经过严格测试，对 root 的危险非常小。
POSIX 功能是将 root 的部分功能委托给其他进程的不同方式（除了 setuid 位）；CAP_NET_BIND_SERVICE例如，允许进程绑定到小于 1024 的端口，而不必是 root。我相信它们是通过扩展属性来工作的。 Fedora 最近（f16？）开始确保所有包都使用功能而不是粘性位。
另一点值得注意，希望是积极的 - unicorn，如果我理解正确的话，是一个 ruby 进程（gunicorn 绝对是一个 python 进程）。使用解释型语言确实降低了开发人员引入错误的风险，因为字符串处理绝对应该是安全的并且指针不可用。然而，解释器的错误也可能会给所有解释程序带来安全风险。
然而，不幸的现实是，流程的妥协www-data对您来说仍然是一个问题；攻击者可能会转储您的数据库、破坏您的网站等。知道 root 是安全的固然很好，但如果您的网站是您面向客户的主要广告点，那么其被破坏仍然对您的业务构成威胁。
概括
是的，以 root 身份运行 unicorn 是有风险的。然而，就以 root 身份执行的代码而言，攻击面相对较小。此外，可能还有一些选项可以最小化您以 root 身份运行的内容。我也没有介绍 SELinux 等 MAC 系统，但假设您准备好学习它们，这些都是可行的选项以及功能。需要了解的重要一点是，风险是一种平衡 - 该服务的敏感/重要程度将决定您应该投入多少精力来保护它。如果您正在运营银行网站，您可能需要认真考虑如何强化系统；如果这是一个托管 lolcat 图片的网站（好吧，你知道我的意思），你可能会认为当前的设置就很好。