执行sudo chmod -R 777 /后系统崩溃，应立即停止操作、恢复sudo权限（chmod 4755 /usr/bin/sudo）和shadow文件权限（chmod 600 /etc/shadow），再通过ACL备份或手动修复关键路径权限。
统信UOS执行sudo chmod -R 777 /后系统崩溃，不是配置错误而是权限契约彻底瓦解：/usr/bin/sudo丢失setuid位导致提权失效、/etc/shadow被设为644可被任意读取、/dev下设备节点权限错乱引发硬件访问拒绝、systemd因单元文件权限异常直接拒载服务——此时系统已丧失可信执行基础，但重装并非唯一出路。
立即止损：黄金窗口期的三步保命操作
若命令刚执行完终端仍可输入（未断开SSH、未重启、未退出当前shell），必须立刻执行以下操作：
第一步：停止一切chmod相关操作，尤其禁止再次执行-R或通配符命令；
第二步：执行chmod 4755 /usr/bin/sudo → 这一步能立即恢复sudo提权能力，因为原sudo二进制文件本身未被删除，仅权限位被覆盖；
第三步：执行chmod 600 /etc/shadow → 【这是防止密码明文泄露的强制动作，若跳过，任何普通用户都可通过cat /etc/shadow直接获取所有账户哈希】；
这三步做完后，sudo即可重新使用，后续修复才有操作基础。若当前shell已无法执行命令（如bash报错“cannot execute binary file”），说明/bin/bash的setuid或动态链接权限也被破坏，需跳转至LiveCD方案。
首选修复：用getfacl+setfacl精准还原原始权限
该方法成功率超90%，前提是有一台同版本（如UOS 20/1070）、未改动过的UOS系统（虚拟机或干净安装环境即可）：
方法一：在正常机器上执行sudo getfacl -pR / > uos-perms.acl（注意-p保留绝对路径，-R是递归，漏掉-R将只导出根目录）；
方法二：将uos-perms.acl拷贝到故障机（可用scp传输，或挂载USB后复制）；
方法三：若故障机仍可启动到emergency shell，先umount /，再执行sudo setfacl --restore=/path/to/uos-perms.acl（路径必须写对，常见错误是把文件放在/root下却写成/home/liveuser/uos-perms.acl）；
方法四：若已无法启动，从UOS官方LiveCD启动 → 终端执行sudo mount /dev/nvme0n1p3 /mnt（请用lsblk -f确认真实根分区）→ sudo mount --bind /dev /mnt/dev → sudo mount --bind /proc /mnt/proc → sudo mount --bind /sys /mnt/sys → sudo chroot /mnt → setfacl --restore=/uos-perms.acl → exit → sudo reboot。
无备份时的手动抢救清单
当完全无法获取同版本ACL备份，只能按模块逐项修复，以下为必须优先处理的五类关键项：
/bin、/sbin、/usr/bin、/usr/sbin中所有特权程序：全部设为4755，包括sudo、su、passwd、ping、mount、umount；
/etc/shadow与/etc/gshadow：必须设为000，否则密码库可被任意读取；
/etc/sudoers：必须设为440，否则sudo会拒绝加载配置；
/tmp和/var/tmp：必须设为1777（带sticky bit），否则systemd、dbus等服务启动失败；
/root目录及其子项：/root设为700，/root/.ssh设为700，私钥文件（id_rsa等）设为600。
