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


这是一个 典型问题 关于文件权限和 为什么 777是“破坏性的”。

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

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


246
2018-02-28 21:25




当我看到这个问题时,我会屏住呼吸。 - Alireza Savand


答案:


首先是一个小术语挑剔: chmod 不 去掉 权限。它 变化 他们。


现在问题的关键 - 模式 777 意思是“任何人都可以读取,写入或执行此文件” - 你有 给予许可 任何人都可以(有效地)做任何他们想要的事情。

现在,为什么这么糟糕?

  1. 您只需让每个人都读取/修改系统上的每个文件。
    • 亲密密码安全再见(任何人都可以阅读影子文件并破解密码,但为什么要这么麻烦?只需更改密码!这就容易多了!)。
    • 为你的二进制文件亲吻安全再见(有人可以写一个新的 login 程序,让他们每次)。
    • 亲吻你的文件再见:一个用户误导 rm -r / 一切都结束了。操作系统被告知让他们做他们想做的事!
  2. 在启动之前,你已经厌倦了检查文件权限的每个程序。
    sudosendmail,以及许多其他人根本不会再开始了。他们将检查密钥文件权限,看看它们不是它们应该是什么,并回放错误消息。
    同样 ssh 将破坏可怕(密钥文件必须具有特定权限,否则他们是“不安全”,默认情况下SSH将拒绝使用它们。)
  3. 你已经清除了拥有它们的程序上的setuid / setgid位。
    模式 777 实际上是 0777。在那个领先的数字中的东西是 setuid 和 setgid 位。
    大多数setuid / setgid程序都设置了该位,因为它们必须以某些特权运行。他们现在坏了。
  4. 你破了 /tmp 和 /var/tmp 在那个得到零的前导八进制数字中的另一个是 sticky bit  - 保护文件的那个 /tmp (和 /var/tmp)不被拥有它们的人删除。
    (不幸的是)有很多表现不好的脚本,通过这样做来“清理” rm -r /tmp/*,并且没有设置粘滞位 /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 环境变量(你不应该!) - 这可能会导致令人不快的惊喜,因为现在任何人都可以删除一个方便地命名为命令的文件(比如说) make 要么 ls,并有机会让你运行他们的恶意代码。
    Credit to @RichHomolka for pointing out this possibility
  8. 在某些系统上 chmod 将重置访问控制列表(ACL)
    这意味着除了在任何地方修复权限之外,您可能还必须重新创建所有ACL(并且这是命令具有破坏性的实际示例)。
    Credit to @JamesYoungman for pointing out this possibility

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


335
2018-02-28 21:46



至少在某些系统上 /tmp 将在重新启动后修复。虽然其他很多事情似乎都被打破了。至少在VM中,我刚刚测试了它,看起来重新启动了 /tmp 权限。某处的启动脚本中必定存在某些内容。 - Zoredache
@Zoredache使用的系统 tmpfs 通常修复自己,在磁盘上有/ tmp的 可以 (取决于他们的启动脚本) - voretaq7
+1指出setuid和setgid将被删除。这是一个非常具有破坏性的方面。试试跑步 find / -perms -4000 -type f 和 find / -perms -2000 -type f 查看依赖这些标志的各种二进制文件。 - Kyle Smith
键入类似“less foo.txt”的内容不会执行名为less.txt的文件,无论可执行位是否设置。您需要在路径中包含less.txt目录,并且您必须键入“less.txt foo.txt” - 这并不是偶然的事情。即使你使用shell完成它也会停止,你仍然需要添加.txt。要调用具有可执行位设置的随机文本文件,您必须使用./nameoffile.txt。 - The Real Bill
@Deji everyone 被定义为集合的并集,包括拥有该文件的用户,拥有该文件的组中的用户,以及不满足这些标准的用户(字面意思是三个八进制权限数字: User, Group,和 Other)。换一种说法 任何有权访问系统的用户。 (在此上下文中的“访问”可以是一个shell帐户,这是我通常会解决的问题,但它还包括通过Web表单/ CGI访问,该数据将数据写入磁盘: www 用户现在可以写入系统上的任何文件,这意味着随机访问者也可以。) - voretaq7


一个主要的事情是有许多工具,如ssh / sudo,它们检查密钥配置文件的文件系统权限。如果权限错误,则这些工具会失败,因为这会表明存在严重的安全问题。在我的Debian测试系统上,也许在其他系统上,登录的能力失败,可能是因为登录二进制文件或PAM中的某些东西有权限检查。

因此系统不会被破坏 - 很多工具被设计为在权限错误时立即失败。

如果在执行之后重新启动系统 chmod 777 -R / 它将启动,您可以启动没有明确权限检查的进程。所以系统并没有真正死亡,只是有些无法使用 通过设计


100
2018-02-28 21:33