权限恢复不能靠定时任务自动执行，必须依赖事先生成的、与系统版本严格匹配的acl快照；快照需来自同发行版/版本/架构的干净系统，通过getfacl -r生成并存于外部存储，恢复时需人工介入验证关键权限及特殊位。
权限恢复不能靠定时任务自动跑
Linux 文件权限恢复不是能写个 cron 定时脚本就完事的事——setfacl --restore 依赖的是事先生成的、与当前系统版本严格匹配的权限快照。没有快照，定时任务只会报错 setfacl: unable to restore ACL: Invalid argument 或静默失败。
- 快照必须来自同发行版、同大版本、同架构的干净系统（比如 CentOS 7.9 x86_64 的快照不能用于 CentOS 7.6）
-
getfacl -R /生成的备份文件体积巨大（常超百 MB），频繁执行会拖慢 I/O，且每次备份内容几乎不变，无实际价值 - 权限被破坏后，cron 服务本身可能已因
/etc/cron.d/权限错误或/var/spool/cron属主错乱而无法触发
真正该配置的是一次性快照生成流程
权限恢复的“配置”本质是建立可复用的备份链路，不是调度任务。重点在事前准备：
- 在新部署的同版本服务器上线后立即执行：
getfacl -R / > /root/system-perm-$(hostname)-$(date +%Y%m%d).facl - 把备份文件同步到集中存储（如 NFS 或对象存储），并校验 MD5：
md5sum /root/system-perm-*.facl - 记录对应系统的
rpm -qa | sort > packages-list.txt或dpkg --get-selections > packages-list.txt，用于后续验证包一致性 - 禁止把快照存在本地磁盘——万一
/被误chmod -R，备份文件权限也会损坏，失去恢复意义
恢复时要绕过 systemd 和 cron 的依赖
权限全乱之后，systemd 可能拒绝启动服务，cron 根本不运行。必须预设脱离依赖的入口：
- GRUB 启动参数中预留
rd.break（RHEL/CentOS）或init=/bin/bash（通用），确保能挂载 root 为可写 - 准备一个最小化恢复脚本（如
/root/fix-perm.sh），只依赖bash和setfacl，不调用任何外部命令或配置文件 - 脚本开头强制检查关键路径权限：
[ -f /root/system-perm-*.facl ] || { echo "no backup found"; exit 1; } - 避免在脚本里写
reboot——恢复后需人工确认ls -l /bin/sudo是否为-rwsr-xr-x，再决定是否重启
最易被忽略的细节：ACL 恢复不等于 chmod 复位
setfacl --restore 只还原 ACL 条目，但不会自动修复 setuid/setgid 位、粘滞位（sticky bit）或文件属主。例如：
-
/usr/bin/sudo权限被改成0755后，setfacl --restore不会把它变回4755 -
/tmp目录若丢失了t位（即从1777变成0777），ACL 快照里也未必保留该信息 - 必须单独补一条：
chmod u+s /usr/bin/sudo /bin/su && chmod +t /tmp - 检查
/etc/shadow权限是否为000、/etc/sudoers是否为440——这些在快照里虽有记录，但若原始快照生成时已有偏差，就会连带出错
