我认为这篇文章听起来合乎逻辑，但得出了错误的结论。 确实，当人们讨论“需要” root 访问权限时，首先想到的是 1024 以下的端口号和修改内核设置。 但是，这篇文章不加批判地接受了“用户应该拥有完成工作所需的最低访问权限”的观点。 这种想法或最佳实践在今天被广泛接受，但其影响却很少被讨论。 这种思维方式的增加会并且确实会显着增加生产故障和安全事件的风险。
原因如下：当彻底调查生产故障时，通常会有许多促成根本原因——通常是四个、五个或更多。 我的经验是，人为的无知通常至少是其中两到三个因素的一部分。 当“系统管理员”成为一种既定的职业道路时，程序员拥有 root 权限变得不那么常见——所有这些都是出于非常合乎逻辑的良好意图。 这样做的一个意想不到的后果是，开发人员作为一个群体，对他们的软件在生产中的实际行为方式了解较少。 Linux 已经发展成为一个更易于观察的操作系统，具有复杂的跟踪工具——其中许多工具需要 root 权限。 与此同时，今天的多插槽、多核硬件更加强大，也更加复杂。 然而，随着硬件变得越来越强大，很明显性能和安全性似乎仍然停滞不前。 为了让应用软件充分利用开发人员的愿望，他们需要了解他们的代码如何与机器交互——虚拟机、容器和 Java（3 个巨大的积极发展）的普及都掩盖了这一点。 不幸的是，遵循安全最佳实践可能会将我们带入不太安全的环境，在这些环境中，没有人了解整个系统。
为了进一步连接要点... 这就是我所说的开发人员理解系统如何使用资源的意思“应用程序 X 有 100 多个线程。 其中三个是热线程，在一个核心上旋转 - 市场数据事件处理程序和两个工作线程。 大多数剩余线程是每个连接线程的线程，这些线程在大多数时候都是冷的。 然后有四个暖线程 - 记录器、持久化器... 我们希望市场数据事件处理程序始终在插槽 1 上运行，因为市场数据 NIC 在第二个 PCI-X 插槽上，并且该线程可以保持 NUMA 本地。 这个应用程序是一个延迟比吞吐量更重要的应用程序，因此我们不使用默认的 NIC 中断合并设置，...”
验证这些前提条件是否为真的最佳方法是使用 ethtool、perf-test（两者都需要 root 权限）。 因此，问题不应该是“我们需要 root 访问权限吗？”，而应该是“拥有 root 访问权限是否有意义？” 与在 root shell 中偶尔出现人为错误相比，我看到更多的是由于开发人员和 SA 不了解他们的系统如何运行而造成的损害。 我认为应该审核 root 访问权限 - 了解主机最好的学习经验之一就是简单地执行sudo -shistory | more
我认为这篇文章听起来合乎逻辑，但得出了错误的结论。 确实，当人们讨论“需要” root 访问权限时，首先想到的是 1024 以下的端口号和修改内核设置。 但是，这篇文章不加批判地接受了“用户应该拥有完成工作所需的最低访问权限”的观点。 这种想法或最佳实践在今天被广泛接受，但其影响却很少被讨论。 这种思维方式的增加会并且确实会显着增加生产故障和安全事件的风险。
原因如下：当彻底调查生产故障时，通常会有许多促成根本原因——通常是四个、五个或更多。 我的经验是，人为的无知通常至少是其中两到三个因素的一部分。 当“系统管理员”成为一种既定的职业道路时，程序员拥有 root 权限变得不那么常见——所有这些都是出于非常合乎逻辑的良好意图。 这样做的一个意想不到的后果是，开发人员作为一个群体，对他们的软件在生产中的实际行为方式了解较少。 Linux 已经发展成为一个更易于观察的操作系统，具有复杂的跟踪工具——其中许多工具需要 root 权限。 与此同时，今天的多插槽、多核硬件更加强大，也更加复杂。 然而，随着硬件变得越来越强大，很明显性能和安全性似乎仍然停滞不前。 为了让应用软件充分利用开发人员的愿望，他们需要了解他们的代码如何与机器交互——虚拟机、容器和 Java（3 个巨大的积极发展）的普及都掩盖了这一点。 不幸的是，遵循安全最佳实践可能会将我们带入不太安全的环境，在这些环境中，没有人了解整个系统。