如何在Linux中配置权限自动修复脚本-LINUX-PHP中文网

linux没有开箱即用的权限自动修复机制，必须通过systemd-tmpfiles.d定义静态基线（如z/z规则修复/etc/shadow、/etc/sudoers等关键文件）或编写带dry-run、白名单和验证的脚本实现，盲目递归chmod会破坏setuid、sticky bit等关键权限。

如何在linux中配置权限自动修复脚本

直接上结论：Linux 中没有开箱即用的“权限自动修复”机制，必须自己定义基线、编写脚本、并配合 systemd-tmpfiles.d 或定时任务固化执行。盲目运行 chmod -R 会破坏 setuid、目录 sticky bit 等关键位，比不修更危险。

哪些文件该进自动修复白名单

不是所有文件都适合被脚本改权限。真正需要自动修复的，只有明确知道其安全基线的系统配置文件或服务路径：

/etc/shadow 必须是 000 或 400，其他值一律告警+修复
/etc/sudoers 和 /etc/sudoers.d/ 下所有文件必须为 440，644 或 755 就算越权
/etc/ssh/sshd_config 建议 600，若属组需协作可设 640，但绝不能 644 或更宽
/etc/crontab、/etc/cron.d/ 下文件必须 600 或 644（仅 root 写）
不要把 /etc/passwd 加入自动修复——它本就该是 644，改错反而导致 login 失败

用 tmpfiles.d 实现启动时自动修复

systemd-tmpfiles 是最稳妥的“开机即修复”方案，它不依赖 cron，也不怕脚本被 kill，只要系统能启动就能生效：

Zynq Linux Hardware Debug

Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。

下载

在 /etc/tmpfiles.d/fix-perms.conf 中写入规则，例如：

z /etc/shadow 000 root root -<br>Z /etc/sudoers 0440 root root -<br>z /etc/ssh/sshd_config 0600 root root -

z 表示“设置目录权限”，Z 表示“设置文件权限”，两者不混用
规则生效无需重启，运行 sudo systemd-tmpfiles --prefix=/etc --create 立即触发一次
注意：tmpfiles.d 不支持条件判断，所以只适合静态基线；动态路径（如 Python venv）不能用它

Shell 脚本修复必须带 dry-run 和白名单校验

手写修复脚本最容易踩坑的地方是“过度递归”和“覆盖正确权限”。必须强制加防护：

默认只打印将要执行的 chmod / chown 命令，加 -y 参数才真实执行
用 stat -c "%a %U:%G %n" $file 获取当前权限，避免解析 ls -l 输出出错
修复前先检查文件是否存在、是否为普通文件（跳过符号链接和设备文件）：
```
[[ -f "$file" ]] || continue
```
白名单硬编码路径，禁止通配符递归："/etc/shadow" "/etc/sudoers" 可以，/etc/* 绝对不行
对 /etc/sudoers.d/ 这类目录，用 chmod -R go-w /etc/sudoers.d/ 比 chmod 440 更安全，因为它只移除写权限，不改动已有的读/执行位

修复后必须验证是否真生效

权限改了≠功能正常。尤其要注意以下三处静默失败点：

sshd 服务不重启，/etc/ssh/sshd_config 权限改对也没用——得跑 sudo systemctl reload sshd
sudo 会缓存配置，改完 /etc/sudoers 后，用 sudo -l -U $USER 验证策略是否加载
脚本修复后，立刻用 sudo -u nobody stat /etc/shadow 2>/dev/null 测试是否真不可读——别只信 ls -l 输出