auditd 是唯一能查到“谁改了权限”的机制；它通过监听 chmod、chown 等系统调用，记录 uid、pid、exe 路径、目标路径等完整操作溯源信息，且 root 也无法绕过，需手动配置规则并持久化至 /etc/audit/rules.d/。
auditd 是唯一能查到“谁改了权限”的机制
Linux 没有默认开启操作溯源功能，ls -l 只能看到当前权限和 ctime（元数据变更时间），find -cmin -60 也只能筛出“被改过”的文件，完全无法回答“谁、用什么命令、在哪台终端、以什么身份改的”。真正能锁定操作源头的，只有内核级审计服务 auditd。
它通过监听 chmod、chown、fchmodat 等系统调用，记录 UID、PID、exe 路径、目标路径、时间戳，且 root 执行也无法绕过。
- 规则必须手动添加，不启用就永远没记录
- 日志存于
/var/log/audit/audit.log，不可被普通用户删除或覆盖 - 规则持久化要写进
/etc/audit/rules.d/perm.rules，否则重启后失效
快速启用并查询权限变更记录
执行以下命令立即捕获后续所有权限操作：
sudo auditctl -a always,exit -F arch=b64 -S chmod,fchmod,fchmodat,chown,fchown,fchownat,setxattr -k perm_change
查最近 24 小时的完整记录（含用户、命令、路径）：
sudo ausearch -k perm_change --start yesterday | aureport -f -i
输出示例中关键字段：
-
acct：操作用户名（不是 UID 数字） -
comm：实际执行的命令名（如chmod、python3） -
exe：可执行文件绝对路径（区分脚本调用还是直接二进制） -
cwd：执行时所在目录（辅助判断上下文） -
path：被修改权限的目标文件或目录
sudo 权限操作可交叉验证
如果变更大概率是人工通过 sudo 发起的，/var/log/auth.log 或 /var/log/secure 里会有前置日志，但仅限走 sudo 的场景：
- Debian/Ubuntu：
grep "sudo.*chmod\|sudo.*chown" /var/log/auth.log | tail -20 - RHEL/CentOS：
grep "sudo.*chmod\|sudo.*chown" /var/log/secure | tail -20
注意：auth.log 不记录直接 root 执行、cron 脚本调用、或容器内进程行为，只能作为 auditd 的补充线索。
auditd 未启用时的应急缩小范围法
若系统没开 auditd 又急需排查，只能靠静态信息反推时间窗口：
- 对可疑文件运行
stat /path/to/file，看Change时间（即 ctime） - 用
last -n 50查该时刻前后 10 分钟内有哪些用户登录过 - 用
w或who -u看当前活跃会话，比对登录时间与 ctime 是否重合 -
ps aux --forest查当时是否在跑可疑脚本（需结合etime字段估算启动时间）
这种办法无法确认操作动作本身，只能把嫌疑人范围从“所有人”缩到“那几个刚登录的用户”，真正要坐实是谁改的，auditd 规则必须提前部署——等出事再装，记录已经丢了。
