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 覆盖过，属主就和实际修改者完全脱钩。

Linux Security Scanner

Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...

下载

• stat /path/to/file 输出里的 Uid 和 Gid 是当前值，和 Modify 时间无因果关系
• 常见误判场景：root 用 cp 替换文件 → 属主变成 root，但实际操作者可能是普通用户
• 哪怕文件权限是 644，只要没设 chattr +a 或 ACL，任何人都可能通过 sudo 绕过属主限制

inotifywait 只能记录事件，不能记录用户身份

inotifywait 是用户态工具，它监听的是文件系统事件，本身不抓取调用进程的 UID —— 它看到的 whoami 是运行该脚本的用户，不是触发修改的真实用户。

• 比如你用普通用户启动监控脚本，另一个人用 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 表示标准输出写入）人工判断

审计规则一旦漏配、服务未启动、日志轮转未保留，就再也找不回那个“谁”。真正的难点不在命令怎么敲，而在规则是否覆盖了目标路径、是否在修改发生前就已生效、日志是否留存足够久——这些都得靠运维习惯，而不是临时翻文档。