Linux不默认记录文件读取行为，仅维护atime/mtime/ctime三时间戳；atime常被relatime或noatime禁用，不精确；需auditd审计框架才能准确追踪“谁在何时读何文件”。
Linux 没有默认记录文件“谁在什么时候读过”的日志
系统本身不保存普通文件的读取行为（read()、cat、less 等），这是设计使然：开销太大，且多数场景不需要。你查不到“张三在 14:23 用 vim 打开了 /etc/passwd”这种记录——除非提前配了审计机制。
能查到的，只有内核维护的三个时间戳：atime（最后访问时间）、mtime（最后修改时间）、ctime（最后状态变更时间）。其中 atime 理论上最接近“读取时间”，但它常被禁用或延迟更新。
-
atime默认可能不准确：多数发行版挂载时加了relatime或noatime，避免每次读都写磁盘 -
stat命令看到的Access时间，只是上次触发更新的那个时刻，不是精确读取时间点 - 即使启用了
strictatime，它也只记录“至少一次读”，无法区分是grep还是cp触发的
怎么查看当前文件的 atime（最后访问时间）
用 stat 最直接，但要注意输出字段含义：
stat /var/log/syslog
关注输出中的 Access: 行，例如：Access: 2024-05-20 16:02:17.123456789 +0800。这不是“最后一次被 cat 的时间”，而是该文件 inode 的 atime 字段值。
- 如果挂载选项是
noatime，这个时间永远不会更新，始终是旧值 - 如果是
relatime（默认常见），只有当atime老于mtime或ctime时才更新，所以它往往滞后甚至“冻结” -
ls -lu也能显示访问时间，但精度低（只到秒），且受LC_TIME影响格式
想真正在意“谁读过什么”，得上 auditd
auditd 是 Linux 内核提供的审计框架，能记录指定系统调用（如 openat、read）的详细上下文，包括进程名、UID、命令行参数。
启用前先确认服务已装并运行：
sudo systemctl enable auditd && sudo systemctl start auditd
- 监控单个文件：用
auditctl -w /etc/shadow -p r -k shadow_read（-p r表示只监读操作） - 查记录：
sudo ausearch -k shadow_read | aureport -f -i，会列出 UID、exe、cmdline 等 - 注意：规则不会持久化，重启 auditd 后失效；要永久生效，得写进
/etc/audit/rules.d/下的规则文件 - audit 日志量大，频繁读小文件（比如
/proc下）容易撑爆/var/log/audit/，别乱加全局规则
为什么别依赖 atime 做安全审计或行为分析
它太弱了：不记录主体（用户/进程）、不区分读写、不保证更新、还可能被绕过（比如用 dd if=... of=/dev/null 读块设备，atime 不动）。
- 容器环境里，宿主机的
atime对容器内文件基本无效（挂载传播和命名空间隔离影响） - ext4 默认启用
relatime，XFS 更激进，默认就是noatime行为（除非显式关掉） - 哪怕你改了
/etc/fstab加strictatime，只要应用用O_NOATIME标志打开文件，atime依然不更新
真要追溯访问链路，auditd 是唯一靠谱路径；其他方案，都是在猜。
