auditd是唯一能精准回溯文件属主变更的方案，它通过捕获内核级chown、fchownat等系统调用，记录uid、进程名、命令行及时间戳等完整上下文，而stat、ls -l仅显示当前状态，无法溯源操作者。
Linux本身不记录“谁修改了文件”这一信息，stat、ls -l 看到的 Uid 和属主（user）只是当前文件所有者，不是历史修改者；mtime 只告诉你是“什么时候改的”，不告诉你“谁改的”。
要真正查到修改者，必须提前部署审计机制。没开 auditd，事后基本无法回溯。
auditd 是唯一靠谱的实时追踪方案
它通过内核级审计规则捕获系统调用，能精确记录 UID、EUID、命令路径、时间等字段。
- 先确认 auditd 已安装并运行：
sudo systemctl status auditd - 添加监控规则（例如监控
/etc/hosts）：sudo auditctl -w /etc/hosts -p wa -k hosts_mod（-p wa表示写入 + 属性变更） - 触发一次修改（如
echo "127.0.0.1 test" | sudo tee -a /etc/hosts） - 查日志：
sudo ausearch -k hosts_mod | aureport -f -i，输出里会有uid=0、auid=1000（登录用户）、comm="tee"等关键字段 - 注意：规则重启后失效，需写入
/etc/audit/rules.d/下的 .rules 文件并sudo augenrules --load
ls -l 和 stat 只能看当前属主，不是修改者
ls -l /path/to/file 显示的是文件当前所有者（Uid），不是最后一次修改它的人。如果文件被 sudo chown 过、或被其他用户 cp --preserve 覆盖过，属主就和实际修改者完全脱钩。
-
stat /path/to/file输出里的Uid和Gid是当前值，和Modify时间无因果关系 - 常见误判场景：root 用
cp替换文件 → 属主变成 root，但实际操作者可能是普通用户 - 哪怕文件权限是
644，只要没设chattr +a或 ACL，任何人都可能通过 sudo 绕过属主限制
inotifywait 只能记录事件，不能记录用户身份
inotifywait 是用户态工具，它监听的是文件系统事件，本身不抓取调用进程的 UID —— 它看到的 whoami 是运行该脚本的用户，不是触发修改的真实用户。
Linux Security Scanner
下载
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
- 比如你用普通用户启动监控脚本，另一个人用
sudo vim /target/file修改，脚本里$(whoami)输出仍是你的用户名，不是 root - 若想补全用户信息，必须配合
ps -o uid,comm -p $PPID或解析/proc/$PID/status，但依然不可靠（进程可能已退出） - 它适合轻量通知，不适合审计取证
lsof 可查“正在修改”的进程，但不适用于历史修改
lsof +D /path 或 lsof /path/to/file 只能列出当前打开该文件的进程，对已完成的写入操作无效。
- 典型用途：发现某个配置文件正被 nginx 占用，无法直接
mv替换 - 它返回的
USER列是进程的有效 UID，但只反映“此刻”状态；修改早已完成的文件不会出现在结果中 - 无法区分是读取、写入还是 mmap，需结合
FD列（如1w表示标准输出写入）人工判断
审计规则一旦漏配、服务未启动、日志轮转未保留，就再也找不回那个“谁”。真正的难点不在命令怎么敲，而在规则是否覆盖了目标路径、是否在修改发生前就已生效、日志是否留存足够久——这些都得靠运维习惯，而不是临时翻文档。
