linux文件系统不记录详细修改历史，auditd是唯一可靠的内核级审计方案，需root权限配置精确路径规则，日志存于/var/log/audit/audit.log；inotifywait仅适合临时轻量监听，stat/find等命令无法提供真实操作证据。
Linux 没有默认记录文件修改历史
Linux 文件系统（如 ext4、XFS）本身不保存“谁在什么时候改了哪一行”这类操作日志。你用 ls -l 看到的 mtime 只是最后修改时间戳，无法区分是编辑、覆盖、cp 还是 touch 导致的——它会被所有写入操作刷新，且容易被 touch 伪造。
auditd 是唯一靠谱的内核级审计方案
要真实捕获文件变动（open/write/unlink 等），必须依赖内核的 audit 子系统，核心组件是 auditd 守护进程和 auditctl 规则管理工具。它工作在系统调用层，绕过 shell 和应用逻辑，可靠性远高于 inotify 或轮询脚本。
- 必须用 root 权限配置，普通用户无法添加审计规则
- 规则需指定具体路径，通配符只支持
-w /path/to/file（精确路径）或-w /dir/（目录递归监控），不支持*.log这类 shell 风格匹配 - 监控目录时，默认只捕获该目录下的直接事件（如新建文件），子目录需单独加规则或启用
-r递归标志（仅较新内核支持） - 日志默认写入
/var/log/audit/audit.log，体积增长快，建议配合logrotate或调整max_log_file配置
示例：监控 /etc/passwd 的所有写入行为：
sudo auditctl -w /etc/passwd -p wa -k passwd_mod其中
-p wa 表示监控 write 和 attribute change（如 chmod），-k passwd_mod 是自定义键名，方便后续用 ausearch -k passwd_mod 快速检索。
inotifywait 只适合轻量、临时监听
如果你只是想在开发或调试时“看一眼”某个配置文件是否被改，inotifywait（来自 inotify-tools 包）够用，但它不是审计工具：它基于 inotify API，只能监听当前会话有效，进程退出就停止；不记录用户 UID、命令行参数，也无法捕获硬链接、rename 等间接修改。
- 安装后立即可用：
sudo apt install inotify-tools（Debian/Ubuntu）或sudo yum install inotify-tools（RHEL/CentOS） - 常用命令：
inotifywait -m -e modify,attrib,move_self,delete_self /path/to/file
-m表示持续监听，-e后列出你要关注的事件类型 - 注意：
modify仅触发内容变更，attrib才捕获权限/属主变化；如果文件被mv替换，原 inode 消失，inotifywait会报delete_self并退出，除非加--monitor（等价于-m）并配合脚本重挂
不要依赖 stat 或 find 查“最近修改”
stat /file 显示的 Modify 时间、find / -mmin -5 这类查找，本质都是读取当前时间戳，不是操作记录。一旦文件被 touch -m、备份工具覆盖、或 NFS 客户端时间不同步，结果就完全不可信。
-
find的-mtime/-mmin计算基于系统当前时间减去文件 mtime，不是事件发生时间 - ext4 文件系统支持
birth time（创建时间），但多数工具（包括stat默认输出）不显示，且只有部分内核版本+挂载选项（inode64等）才真正可靠 - 没有审计规则的前提下，
ausearch或journalctl都查不到文件修改的原始上下文（比如哪个进程、哪个用户、执行了什么命令）
真要回溯改动来源，auditd 规则是唯一能闭环的路径。其它方法全是推测，不是证据。
