auditd需先启用服务、配置精准规则（如监控chown/fchown/fchownat等系统调用）、加载并验证生效，否则/var/log/audit/audit.log中不会记录权限变更操作。
没有现成的“权限审计历史记录”可直接查看，必须先启用 auditd 并配置对应规则，否则 /var/log/audit/audit.log 里根本不会存属主变更、chmod 等操作。
auditd 是否已运行并记录了权限变更
先确认基础状态，避免白查日志：
- 运行
sudo systemctl status auditd，检查服务是否 active (running) - 执行
sudo auditctl -s | grep enabled，输出应为enabled 1 - 查当前加载的规则：
sudo auditctl -l | grep -E "(chown|chmod|setfacl|fchmodat)"，没结果说明没监控权限类系统调用 - 若规则为空，
/var/log/audit/audit.log里自然不会有权限变更记录——它只记你明确告诉它要记的东西
查 chown / chmod 类操作必须匹配系统调用名
权限变更不是靠文件路径模糊匹配，而是捕获内核级系统调用。常见错误是只监听 path=/etc/passwd 却漏掉调用名：
-
chown触发的是chown、fchown、fchownat三个系统调用 -
chmod对应chmod、fchmod、fchmodat - ACL 变更走
setxattr或setfacl（后者本质是调用setxattr） - 正确检索示例：
ausearch -m chown,fchown,fchownat -i | grep "uid="，-i是关键，否则字段全是数字
从 audit.log 里人工识别权限变更事件
直接读原始日志容易漏关键字段，但有时必须这么做（比如 ausearch 不可用或规则未加 -k 标签）：
- 打开
/var/log/audit/audit.log，找含syscall=90（chown）、syscall=91（fchown）、syscall=280（fchownat）的行 - 关键字段含义：
uid=是操作者 UID，comm="chown"是命令名，exe="/usr/bin/chown"是绝对路径，cwd=是执行目录 - 注意：同一操作可能拆成多行（如
SYSCALL+CWD+PATH），需连起来看；PATH行里的nametype=若为UNKNOWN，说明目标文件当时不存在或路径解析失败
为什么 grep /var/log/secure 永远找不到真正的 chown 执行者
/var/log/secure 只记录 sudo、ssh、su 等特权进程的日志，它不捕获内核行为：
- root 直接执行
chown？/var/log/secure不记 - systemd service 启动脚本里调用
chown？不记 - crontab 里跑的
chown？不记 - 它只记 “用户通过 sudo 运行了什么命令”，而不是 “谁改了哪个文件的属主”——这是两个不同层级的事
auditd 是唯一能回溯到真实 UID 和进程上下文的机制；其他所有方法（find -cmin、inotifywait、stat）都只能告诉你“变了”，不能告诉你“谁、在哪儿、为什么变”。
