☰

破坏了 /bin、/boot 和 /dev 的权限；如何清理混乱？

tag-icon • tag-icon permissions boot chmod
破坏了 /bin、/boot 和 /dev 的权限；如何清理混乱？

我刚刚犯了一个严重的错误，我试图自己修复它，但我需要一些帮助。

由于语法错误，所有文件和文件夹权限都被更改：幸运的是，我在发生这种情况时看到了这一点并成功阻止了它。 “仅” /bin、/boot、 和/dev受到影响。以下是所发生事件的摘录（完整日志：http://pastebin.com/4BkbXEqD）：

Apr 11 21:34:08 *** sftp-server[20582]: set "/.newrelic" mode 40754
Apr 11 21:34:08 *** sftp-server[20582]: set "/bin" mode 40554
Apr 11 21:34:09 *** sftp-server[20582]: set "/boot" mode 40554
Apr 11 21:34:09 *** sftp-server[20582]: set "/cgroup" mode 40754
Apr 11 21:34:09 *** sftp-server[20582]: set "/dev" mode 40754
Apr 11 21:34:09 *** sftp-server[20582]: opendir "/.newrelic"
Apr 11 21:34:09 *** sftp-server[20582]: closedir "/.newrelic"
Apr 11 21:34:09 *** sftp-server[20582]: opendir "/.newrelic"
Apr 11 21:34:10 *** sftp-server[20582]: closedir "/.newrelic"
Apr 11 21:34:10 *** sftp-server[20582]: opendir "/"
Apr 11 21:34:10 *** sftp-server[20582]: closedir "/"
Apr 11 21:34:10 *** sftp-server[20582]: opendir "/bin"
Apr 11 21:34:10 *** sftp-server[20582]: closedir "/bin"
Apr 11 21:34:10 *** sftp-server[20582]: set "/bin/mknod" mode 100754
Apr 11 21:34:10 *** sftp-server[20582]: set "/bin/cat" mode 100754
Apr 11 21:34:10 *** sftp-server[20582]: set "/bin/ping6" mode 100754

例如，MySQL 不再运行，恐怕造成的损害更大。

我尝试恢复这些文件夹和文件的读取和执行权限，但实际上我不知道它们之前处于哪种状态。

如何将系统恢复到工作状态？

答案1

如果您设法启动 root shell，您应该能够从 root shell 恢复权限。您应该能够通过在控制台上以 root 身份登录来获取 root shell。此时，根据您的配置，您可能能够也可能无法使用su或的普通帐户获得 root 访问权限sudo，并且您可能无法使用任何非 root 帐户登录。

如果您发布的记录是完整的，那么您很幸运，权限最难恢复的文件（/etc和/var）不会受到影响。

Apr 11 21:34:08 *** sftp-server[20582]: set "/.newrelic" mode 40754
Apr 11 21:34:08 *** sftp-server[20582]: set "/bin" mode 40554
Apr 11 21:34:09 *** sftp-server[20582]: set "/boot" mode 40554
Apr 11 21:34:09 *** sftp-server[20582]: set "/cgroup" mode 40754
Apr 11 21:34:09 *** sftp-server[20582]: set "/dev" mode 40754

40754（八进制表示法）表示一个目录，所有者可写，所有者和组可执行，所有人可读。只有最右边的三位数字表示权限，前面的数字对文件类型进行编码并且无法更改。由于目录的“执行”权限实际上意味着访问该目录中文件的权限，因此大多数用户无法再访问这些目录中的文件。大多数顶级目录应具有权限 755，这意味着每个人都可读和可执行，并且只能由所有者写入（例外情况是/lost+found通常为 700，/tmp必须为 1777，并且特殊文件系统（例如/proc其/sys所有者可能无法写入）。我不知道/.newrelic是什么，它不是标准的顶级目录。

chmod 755 /bin /boot /cgroup /dev

Apr 11 21:34:10 *** sftp-server[20582]: set "/bin/mknod" mode 100754
…

/bin和中的大多数文件/sbin应该可供所有人读取和执行，并且只能由其所有者写入。其中有几个需要设置用户标识。

chmod a+x /bin/* /sbin/*
chmod 4755 /bin/su /bin/sudo /bin/mount /bin/umount /bin/ping /bin/ping6
chmod 4754 /bin/fusermount

在 中/boot，我认为所有文件和目录都应该是世界可读的，并且目录应该是可执行的，但文件不应该。

find /boot -type d -exec chmod 755 {} + -type f -exec chmod 644 {} +

这使得/dev文件之间的权限差异很大。幸运的是，/dev它是一个内存文件系统，因此重新启动后内容会正常。如果您可以并且想要在/dev不重新启动的情况下恢复权限，我认为以下命令可以做到这一点：

udevadm trigger --sysname-match='*'

答案2

事实上，似乎系统受到的影响比日志所说的还要严重！
也许是因为开发文件夹，也许是符号链接...不知道，但是在爬行论坛等并逐个文件夹尝试之后，我终于用以下命令保存了服务器

for package in $(rpm -qa); do rpm --setperms $package; done

特别感谢@Gilles 和他出色的回答
特别感谢！ @dhag 编辑我的问题以删除我的礼貌公式

相关内容