误执行 sudo chmod -R 777 / 后系统崩溃，根本原因是破坏了Linux权限契约：sudo失去setuid位、/etc/shadow可读、/dev设备节点错乱、systemd拒载单元文件；恢复关键在于重建原始权限模型，首选getfacl备份+setfacl还原，次选手动修复特权程序（4755）、敏感文件（如/etc/shadow→000）及关键目录权限。
误执行 sudo chmod -R 777 / 后，系统几乎必然崩溃——这不是配置问题，而是权限契约被彻底破坏。/usr/bin/sudo 失去 setuid 位、/etc/shadow 变成可读、/dev 下设备节点权限错乱、systemd 拒绝加载单元文件……这些不是孤立现象，而是同一根源的连锁反应。恢复的关键不是“改回来”，而是重建系统原本依赖的权限模型。
立即止损：别重启、别退出当前会话
若命令刚执行完但终端仍可用（未断开 SSH 或未重启），这是黄金窗口期：
- 立刻停止任何进一步 chmod 操作，尤其避免再次执行 -R 或通配符命令
- 不要退出当前 shell——因为 /bin/bash 的 setuid 位很可能已被清空，新启动的 bash 可能无法加载动态链接库而直接失败
- 优先尝试修复最基础的提权能力：
chmod 4755 /usr/bin/sudo和chmod 4755 /bin/su（若还能执行） - 临时降权关键敏感文件：
chmod 600 /etc/shadow、chmod 644 /etc/passwd、chmod 640 /etc/group
核心恢复路径：用 getfacl + setfacl 精准还原
这是目前最可靠、最接近原始状态的修复方式，前提是有一台同版本、未改动过的 Ubuntu 系统（虚拟机或干净安装环境即可）：
- 在正常机器上执行：
sudo getfacl -pR / > ubuntu-perms.acl（-p保留绝对路径，R递归，不加-R是常见拼写错误） - 将生成的
ubuntu-perms.acl文件拷贝到故障机（如用scp或挂载 USB） - 在故障机上挂载根分区（若已无法启动，需从 Live USB 进入，然后
mount /dev/sda1 /mnt） - 执行：
sudo setfacl --restore=/path/to/ubuntu-perms.acl（注意路径要写对，若在 chroot 环境中，先chroot /mnt） - 完成后重启，90% 以上情况可恢复正常
手动抢救关键路径（无备份时的次选方案）
若完全无法获取同版本备份，只能按模块逐项修复。以下是最常出问题且必须优先处理的几类：
-
/bin、/sbin、/usr/bin、/usr/sbin 中的特权程序：全部设为
4755（如sudo、su、passwd、ping） -
/etc 下核心配置：
/etc/shadow → 000、/etc/gshadow → 000、/etc/sudoers → 440、/etc/ssh/*_key → 600、/etc/ssh/*.pub → 644 -
/tmp 和 /var/tmp：必须是
1777（带 sticky bit），否则多数服务拒绝启动 -
/root 目录：应为
700；/root/.ssh为700，密钥文件为600 - /proc、/sys、/dev 不参与修复：它们是虚拟文件系统，重启后自动重建，强行 chmod 反而引发新问题
预防比修复重要得多
真正有效的权限管理，不是等崩溃后再补救：
- 永远不在根目录或 /usr、/etc 等系统路径下使用
-R配合 777 - 操作前先用
find /path -type f -perm 777和find /path -type d -perm 777定向扫描，确认范围 - 用
-ok替代-exec，强制每一步交互确认 - 定期在新装系统上运行
sudo getfacl -pR / > perms-backup-$(date +%F).acl，存档备用 - 对 Web 目录等业务路径，优先用组权限（如
chown -R www-data:www-data /var/www+chmod -R 755 /var/www）而非 777
