☰

为什么甚至允许使用可怕的‘rm -rf /’？

tag-icon • tag-icon linux command-line unix root rm
为什么甚至允许使用可怕的‘rm -rf /’？

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

rm -rf /

相关问题：

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

为什么指挥部里没有这样的保障措施呢rm？

我很清楚，以 root 身份执行命令时必须格外小心。拥有强大的力量 (...)。然而，这个具体案例难道不应该是该规则的一个例外吗？

答案1

这取决于发行版。我现在使用的旧版 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，GNUrm将拒绝执行，自 2006 年发布 GNU Core Utilities 6.4 版以来，这一直是默认设置。rm -rf /--preserve-root

答案2

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

目前已经有三项保障措施：

  • 如果没有该开关，目录-r就无法被删除。
  • 此-i开关用于验证您是否确实要删除您要求删除的内容。除非您添加开关将其关闭，否则别名将rm启用rm -i该保护措施。-f
  • 文件所有权，阻止所有用户root删除根目录。

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

然而，这个特定案例难道不应该是该规则的一个例外吗？

至少从 20 世纪 80 年代开始，人们就一直在问为什么我们不能在rm链锯上安装锯片保护罩。（可能更久远，但我与 Unix 的历史并不比那更久远。）你必须问自己更多问题：

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

  • 我们要在哪里执行这些禁令？直接执行rm还是交给内核？由于rm实际上不会删除任何内容（它会根据参数进行大量调用unlink(2)）rmdir(2)，因此内核无法检测到rm真正要删除的内容/，直到真正需要删除它为止。由于只有rmdir(2)在目标目录为空时才会成功调用，因此达到这一点/意味着系统已经完成。

相关内容