为什么“chmod -R 777 /”具有破坏性?

Modified on: Tue, 12 Nov 2019 18:20:02 +0800
  

这是关于文件权限的规范性问题为什么 777是“破坏性的”。

我不是问如何解决这个问题,因为服务器故障(重新安装操作系统)上已有大量的引用。为什么它会做任何具有破坏性的事情呢?

如果您曾经运行此命令,则几乎会立即破坏您的操作系统。我不清楚为什么删除限制会对现有流程产生任何影响。例如,如果我没有对某些内容的读取权限,并且在终端中快速输入错误后,我现在可以很好地访问...为什么会导致Linux崩溃?

最佳答案

首先是一个小术语nitpick:chmod没有删除权限。它更改


现在问题的关键 - 模式777意味着“任何人都可以读取,写入或执行此文件” - 您已经授予任何人可以做的事情( (无论他们想要什么)。

现在,为什么这很糟糕?

  1. 您只需让所有人阅读/修改您系统上的每个文件。
    • 亲密密码安全再见(任何人都可以读取影子文件并破解密码,但为什么要这么麻烦?只需更改密码!这样更容易!)。
    • 为你的二进制文件吻别安全(有人可以写一个新的login程序,让它们每次都可以。)
    • 亲吻你的文件再见:一个用户误导rm -r /而且一切都结束了。操作系统被告知让他们做任何他们想做的事情!
  2. 在启动之前,您已经生效了检查文件权限的每个程序。
    sudosendmail,以及其他一些人根本不会再启动了。他们将检查密钥文件权限,看他们不是他们应该是什么,并回复错误信息
    类似地,ssh可能会破坏(密钥文件必须具有特定权限,否则它们是“不安全的”,默认情况下SSH将拒绝使用它们。)
  3. 您已经清除了拥有它们的程序上的setuid / setgid位。
    模式777实际上是 0 777。该前导数字中的内容包括setuidsetgid位。
    大多数setuid / setgid程序都设置了该位,因为它们必须以某些特权运行。他们现在坏了。
  4. 您已破坏/tmp/var/tmp
    另一个得到零的前导八进制数字是sticky bit - 它保护/tmp中的文件(以及/var/tmp
  5. 您在/dev /proc和类似文件系统中造成了严重破坏
    这对于旧的Unix系统来说更是一个问题,其中/dev是一个真正的文件系统,它包含的东西是用mknod创建的特殊文件,因为权限更改将是在重新启动时保留,但在任何系统上更改设备权限可能会导致严重的问题,从明显的安全风险(每个人都可以阅读每个TTY)到内核恐慌的不太明显的潜在原因。
    Credit to @Tonny for pointing out this possibility
  6. 套接字和管道可能会损坏或出现其他问题
    插座和管道可能完全断裂,或者由于被世界可写而受到恶意注入
    Credit to @Tonny for pointing out this possibility
  7. 您已使系统上的每个文件都可执行
    很多人在.环境变量中都有PATH(你不应该!) - 这可能会导致令人不快的惊喜,因为现在任何人都可以删除一个方便地命名为命令(比如makels,并试图让你运行他们的恶意代码。
    Credit to @RichHomolka for pointing out this possibility
  8. 在某些系统chmod将重置访问控制列表(ACL)
    这意味着除了在任何地方修复权限之外,您可能还必须重新创建所有ACL(并且该命令具有破坏性的实际示例)。
    Credit to @JamesYoungman for pointing out this possibility
  9. 醇>

    系统中已经运行的部分会继续运行吗?可能至少有一段时间了。
    但是下次你需要启动一个程序,或者重新启动一个服务,或者天堂禁止重新启动你所处的盒子,因为上面的#2和#3将会让他们的丑陋头脑重新受伤。


相关问答

添加新评论