![修复意外 chmod debian 后服务器的权限](https://linux22.com/image/1541809/%E4%BF%AE%E5%A4%8D%E6%84%8F%E5%A4%96%20chmod%20debian%20%E5%90%8E%E6%9C%8D%E5%8A%A1%E5%99%A8%E7%9A%84%E6%9D%83%E9%99%90.png)
惊慌失措之下,我错误地在 ubuntu 论坛上发帖,现在我在正确的地方重新发帖了(我认为)
在尝试调试邮件服务器时,我输入了:
chmod -R 777 /
代替:
chmod -R 777 .
更糟糕的是,由于我忘记更改了用于登录修复问题的脚本,所以我以 root 身份执行了所有操作。我没有备份大部分系统(我知道这是一个糟糕的选择)。
与问题“从 chmod -R -777 / 中恢复”和“‘chmod -R 777 /’ 之后该做什么?”不同,我仍然以 root 身份登录,并且整个系统并未更改,因此我确实可以控制系统。我还在一秒钟内退出命令以将损害降到最低。从那时起,我已经将服务器与互联网物理断开。
我相信如果脚本根据来自包管理器的数据恢复文件系统的权限,它就可以修复这个问题,但我不知道该怎么做。如果这不可能,我该如何保存来自服务器的数据以重新安装操作系统?
我知道丢失文件的潜在风险,但尽管如此,我还是希望通过恢复来重新安装。
这是当前的输出ls -la /
:
drwxrwxrwx 22 root root 4096 Sep 7 2016 .
drwxrwxrwx 22 root root 4096 Sep 7 2016 ..
drwxr-xr-x 2 root root 4096 May 18 07:55 bin
drwxr-xr-x 3 root root 4096 Sep 21 07:53 boot
drwxr-xr-x 19 root root 3180 Sep 11 20:54 dev
drwxrwxrwx 92 root root 4096 Aug 23 07:50 etc
drwxr-xr-x 4 root root 4096 May 23 2016 home
lrwxrwxrwx 1 root root 31 Feb 24 2016 initrd.img -> /boot/initrd.img-3.16.0-4-amd64
drwxrwxrwx 18 root root 4096 Feb 24 2016 lib
drwxr-xr-x 2 root root 4096 Jun 20 07:00 lib64
drwx------ 2 root root 16384 May 19 2016 lost+found
drwxrwxrwx 2 root root 4096 May 5 2015 media
drwxr-xr-x 2 root root 4096 May 5 2015 mnt
drwxr-xr-x 3 root root 4096 May 28 2016 opt
dr-xr-xr-x 148 root root 0 Sep 3 21:55 proc
drwxrwxrwx 10 root root 4096 Aug 19 17:58 root
drwxr-xr-x 22 root root 800 Sep 21 17:09 run
drwxrwxrwx 3 root root 4096 Jun 20 07:00 sbin
drwxr-xr-x 4 root root 4096 Sep 20 23:18 sftp
dr-xr-xr-x 13 root root 0 Sep 3 21:55 sys
drwxrwxrwx 8 root root 4096 Sep 21 17:17 tmp
drwxrwxrwx 11 root root 4096 Feb 24 2016 usr
drwxr-xr-x 14 root root 4096 Jun 25 06:21 var
lrwxrwxrwx 1 root root 27 Feb 24 2016 vmlinuz -> boot/vmlinuz-3.16.0-4-amd64
我知道这不是修复邮件服务器的方法。这是一种粗暴的修复方法,目的是查看问题出在哪里。相信我,我不会再这样做了
答案1
如果您可以物理访问此系统,您可以将其驱动器安装到另一个正在运行、正常工作的系统上,至少复制您想要保存的任何数据。这可能是仅恢复数据本身的最安全、最可靠的方法。
您还可以找到一个正常工作的系统的权限(最好是完全相同的操作系统版本,并安装了完全相同的软件包),并更改损坏系统的权限以匹配它 - 再次,如果您可以将损坏系统的驱动器安装到正常工作的系统上,则最容易做到这一点,但如果系统是远程的,并且您仍然可以 ssh 进入它,成为 root 并进行 chmod,那么也可能做到这一点。
笔记:在做任何事情之前,我建议进行完整备份损坏的系统(同样,如果您可以物理访问它,这最容易做到)。如果出现任何问题,请从备份中制作一份新副本,然后重试该副本,保持原始备份不变,以便在再次出现错误时可以再次恢复。
在工作系统上,您应该能够创建一个以空值分隔的文件和工作权限列表,如下所示:
# find / -name '*' -printf '%m %p\0' > working-permissions.txt
边注:它是用空值分隔的,因为您很可能没有任何带有空值的文件名,因此像这样分隔它们比使用换行符更安全(您仍然不太可能有带有换行符的文件名,但安全总比后悔好,而且用空值分隔更安全)。
查看输出以xargs --null -n1 --arg-file=working-permissions.txt echo | less
确保权限和文件名看起来合理。如果它们合理,您现在可以选择以下方法继续:
选项1:
如果你仍然可以登录到损坏的系统并成为 root,你可以尝试将文件复制working-permissions.txt
到损坏的系统并当登录到损坏的系统时跑步:
# perl -0ne '$_ =~ m{^(\d*\d\d\d) (.*)\0$} ; print "chmod $1 $2\n" ; chmod oct($1), $2 ;' working-permissions.txt
选项 2:
您可以将损坏系统中的磁盘安装到正常工作的系统上。现在您需要更改上面的 perl 命令以反映您已将其安装到何处。例如,如果您已将其安装在 上/mnt/broken
,则需要执行以下操作:
# perl -0ne '$_ =~ m{^(\d*\d\d\d) (.*)\0$} ; print "chmod $1 $2\n" ; chmod oct($1), "/mnt/broken/$2" ;' working-permissions.txt
perl 脚本现在将更改中的权限/mnt/broken
。
笔记:选项 2 实际上对工作系统更危险(万一脚本出现错误)。因此,当您准备运行 perl 脚本来更改权限时,我建议您首先使用 LiveDVD 或 USB 驱动器启动工作系统,并且除了损坏系统的驱动器外,不要连接任何其他驱动器。
最后一旦你修复了损坏的系统,经常备份这样,如果再次发生灾难,您就可以从备份中恢复并继续前进。
答案2
/usr
我不建议执行此命令,因为它会破坏您的系统! 、/lib/
、/var
或/sbin
的权限 755/etc
不符合应有的权限。
例如,如果您使用私有主机密钥文件,那么 Sshlogin 之后将无法工作。您将遇到大麻烦。如果机器完全损坏,您根本无法登录 - 好吧,也许这会有所帮助。但之后要恢复正常的系统,您需要从备份中恢复权限!请记住这一点!我吃尽了苦头才学会的......
答案3
真的,如果你备份了设置和数据文件,然后重新安装并恢复文件(具有正确的权限,对于这些文件来说应该很容易,匹配默认目录可能就足够了),这可能是最简单的。但你说服务器无论如何都坏了,所以即使修复了权限它仍然会坏,所以何必呢?只需重新安装即可。
我不知道您的服务器是如何设置的,也不知道数据在哪里,但您应该可以轻松地在网上搜索,而且无论如何,这确实应该是进行备份的第一步。
如果您确实想要一个文件权限列表,您可以进行单独的全新安装(甚至是虚拟机)并将其与当前损坏的安装进行比较,然后根据需要进行调整。
答案4
嗯,对我来说,用户接受的解决方案@kaioker2有效!:-D
就我而言,它恢复了我设置的一些错误权限。因此,我的系统从无法启动恢复到可启动,只有一点小瑕疵。但需要注意的是,我单独执行了每个命令。
chmod -R 755 /bin /boot /dev /etc/ /home /lib /lib64 \
/media /mnt /opt /run /sbin /srv /usr /var
chmod -R 777 /initrd.img /vmlinuz
chmod -R 1777 /tmp
chmod -R 555 /sys
chmod -R 555 /proc
chmod -R 700 /root
如上所述,我再次能够重新启动 Kubuntu。不幸的是,这些命令几乎肯定会破坏sudo 权限。因此,每次当我想要通过 运行程序时,都会遇到以下错误消息sudo
。
sudo: /usr/bin/sudo must be owned by uid 0 and have the setuid bit set
所以我必须通过(K)ubuntu 在第二步修复这个问题恢复模式。这可以通过以下命令完成。(请注意,我并不完全确定这些命令是否真的都是必要的,但就我的情况而言,它们是有效的。)
chown root:root /usr/bin/sudo && chmod 4755 /usr/bin/sudo
chown root:root /usr/lib/sudo/sudoers.so && chmod 4755 /usr/lib/sudo/sudoers.so
chown root:root /etc/sudoers
简短补充一下,我注意到dmesg
日志中有几条Configuration file xyz.conf is marked executable. Please remove executable permission bits. Proceeding anyway.
消息。以下命令修复了这些问题,所以我的 dmesg 日志又“干净”了。
sudo chmod 644 /lib/systemd/system/*
sudo chmod 644 /usr/lib/systemd/system/rc-local.service.d/debian.conf
进一步补充一下,在 KDE 环境中有时似乎也需要进行以下权限更正。
sudo chmod 4754 /usr/lib/dbus-1.0/dbus-daemon-launch-helper