记一次 Linux 服务器误操作与抢救历程

今天，我不知怎么操作...把 /usr 目录的所有者改成 www 用户和 www 用户组了，然后就...

shell
1sudo: /usr/bin/sudo must be owned by uid 0 and have the setuid bit set

起因

其实，我就在 一个项目的目录 执行了 sudo chown -R www *，但是，莫名其妙的...整个 /usr 目录就全部归属了 www: www 的权限，emm...我甚至都不知道问题怎么出来的，但是这个时候还是要保持冷静，分析一下当前的情况：

1. sudo 无法使用，root 用户未设置过密码，无法登录
2. 系统部分命令二进制文件会因为权限问题出错，不过链接 /bin 中的核心命令安全
3. 我们有对主机（服务器）的物理访问权限
4. Ubuntu Server 内置了 recovery mode

如何恢复系统的正常使用？

抢救

emm...linux 嘛，（按我总救挂了的 Arch 来说） 只要不 rm 都能救回来的，我们首先拿回 sudo 再说

我们重启时候，等待开机时候长按 shift 呼出 grub 高级选项（远程服务器也可以直接 vnc 连接上去），选择 recovery mode，等待开机日志之后就可以选择 root 模式进入，这里我们有了 root 就安全啦

思路就是我们可以借助包管理器覆盖安装，将会重写软件的执行文件和安装目录的权限

我们首先用 root 权限覆盖之前所有的更改：

shell
1chown -R root:root /usr

可以参考正确的权限：

然后我们先救 sudo，之后在 ssh 上慢慢操作，

shell
1apt install sudo --reinstall

终于回来了，现在拿到了 sudo 只要慢慢解决就好了

离开之前可以为 root 设置下密码以防万一

shell
1passwd root

解决

有了权限，我们就要慢慢解决问题了

首先可以尝试修复损坏和依赖有问题的包：

shell
1sudo apt update --fix-missing
2sudo apt update --fix-broken
3sudo apt install -f

还记得我们之前的想法是覆盖所有包吗，这类操作的思路都是获取已经安装的软件包列表，通过管道符重新传进入并覆盖安装

shell
1dpkg --get-selections | grep -v deinstall | awk '{print $1}' > packages.txt
2sudo apt install --reinstall $(cat packages.txt)

注意这里可能会出现 Conflicts，比如这里我因为 n 卡的驱动冲突，这里不能正常安装，那就先把 n 卡驱动删掉，反正服务器上这个影响不是很大，救活要紧，总之经过漫长的等待之后...大概会装几百到一千个包，然后你的 /usr 就满血复活了。

其他提醒

为了避免类似问题再次发生，建议：

• 在执行 chown 或 chmod 命令时，确保你明确知道自己在做什么，尤其是在使用 -R 递归选项时。
• 定期备份重要数据和系统配置文件。
• 确保 root 用户设置了密码，以便在紧急情况下可以使用 su 切换到 root 用户。

总结

好吧，吃一堑长一智，说实在的...我到现在也没明白到底怎么造成的，usr这个路径都没输入过。

不过还好面临这个问题我没有慌，还是表面云淡风轻内心其实也很麻木地解决了这个问题，（毕竟救过很多次Arch了）

就这样，希望没有下一次了...