为什么可怕的 'rm -rf /' 甚至被允许？

Question

我们都知道以 root 身份执行以下命令的破坏力：

rm -rf /

相关问题：

• 使用“rm -rf /”命令你能走多远？
• 删除所有内容：# rm -rf /

我看不出这种特殊的参数组合何时会有用，因为它会破坏整个系统，并且有更有效的方法来做到这一点。该rm命令可以检查这些特定参数，并实施某种保护措施 - 尽管有-f参数，但至少要求确认。

为什么rm命令里没有这样的保障？

我很清楚，当您以 root 身份执行命令时必须格外小心。拥有强大的力量（...）。但是，这种特定情况不应该是该规则的例外吗？

Answer 1

为什么 rm 命令中没有这样的保护措施？

已经有了三个保障：

• 的-r开关，没有它的目录不能被删除。
• 该-i开关，它证明你确实要删除您要求删除的内容。除非您添加开关以将其关闭，否则别名rm将rm -i打开该保护措施-f。
• 文件所有权，防止所有用户root删除根目录。

Unix 工具集就像一把电锯：它被设计用来做非常强大的事情，并由了解他们正在做什么的人使用。那些粗心大意的人最终很可能会伤到自己。这并不是说有经验的人不会犯错，显然 Sun 和其他人认为用户root需要自我保护。

但是，这种特定情况不应该是该规则的例外吗？

rm至少从 1980 年代以来，人们一直在问为什么我们不能在电锯上安装刀片防护罩。（可能更长，但我在 Unix 上的历史不会比这更进一步。）你必须问自己更多的问题：

• 既然我们添加了例外，那么还有什么应该被视为神圣的？我们是否应该防止递归删除根目录中的任何内容以避免类似的破坏性错误rm -rf /*？用户的主目录呢？怎么样/lib还是/bin？我们是否必须有一个特殊版本rm来防止在具有非传统文件系统布局的系统上出现这些错误？

• 我们在哪里执行这些禁令？就在rm还是我们给内核的工作吗？由于rm实际上并没有删除任何东西（这让很多电话来unlink(2)，并rmdir(2)根据参数），就没有办法为内核，以检测rm是真的开枪/，直到此刻实际来删除它。由于唯一rmdir(2)会成功的调用是在目标目录为空时，因此到达该点/意味着系统已经完成。

Answer 2

这取决于分布。我现在使用的较旧的 Linux 允许它（我认为，虽然没有对其进行测试 :-) ）并声明man rm：

   --no-preserve-root do not treat '/' specially (the default)

   --preserve-root
          fail to operate recursively on '/'

在许多最近的发行版中，您需要明确添加--no-preserve-root以禁用保护措施。否则将无法执行。

对于Ubuntu的，看到这个问题，其中这种行为进行了讨论。

根据维基百科，这种保护的历史：

Sun Microsystemsrm -rf /在 2005 年首次发布的 Solaris 10 中引入了保护。执行该命令后，系统现在报告/不允许删除。不久之后，相同的功能被引入到 FreeBSD 版本的rm实用程序中。如果给出该选项，GNU 将rm拒绝执行，这是自 2006 年发布 GNU Core Utilities 6.4 版以来的默认设置。rm -rf /--preserve-root