Linux默认不记录文件读取日志，需提前配置auditd或bpftrace；stat的Access时间不可靠，因relatime/noatime挂载选项使其失效，且不记录用户、进程等审计信息。
Linux 默认不记录“谁在什么时候读过哪个文件”这种访问记录。你查不到类似“用户A在14:23用cat打开了/etc/passwd”的日志——除非提前配了审计机制。
stat 看到的 Access 时间不是可靠访问记录，ls -lu 更不准；inotifywait 只能捕获部分打开行为；真要追溯，得靠 auditd 或 bpftrace。
为什么 stat /path 显示的 Access 时间不可信
内核维护的 atime 字段理论上表示最后访问时间，但实际几乎失效：
- 多数系统挂载时用了
relatime（默认）或noatime，atime不再随每次读更新 - 即使启用
strictatime，它只标记“至少被读过一次”，不记录次数、进程、用户，也无法区分cat、grep或dd -
dd if=/dev/sda of=/dev/null这类绕过 VFS 的块设备读取，atime完全不动 -
stat输出的Access:行只是 inode 里那个字段的快照，不是审计证据
auditctl 监控单个文件读取的实操要点
这是唯一能在生产环境稳定落地的方案，但必须手动配置规则并持久化：
- 先确认服务运行：
sudo systemctl is-active auditd，未运行则sudo systemctl enable --now auditd - 加临时规则（重启后失效）：
sudo auditctl -w /etc/shadow -p r -k shadow_read，其中-p r表示只监读操作 - 查记录用：
sudo ausearch -k shadow_read | aureport -f -i，输出含 UID、exe 路径、命令行参数 - 永久生效：把规则写进
/etc/audit/rules.d/shadow.rules，内容同上，然后sudo augenrules --load - 注意日志膨胀：
/var/log/audit/audit.log可能被高频读撑爆，别对/proc或日志轮转目录加-p r
bpftrace 抓 read 系统调用的轻量替代方案
当 auditd 太重或权限受限时，bpftrace 是更底层、更灵活的选择，但需内核支持 eBPF：
- 统计各进程对 fd 的读频次（无路径）：
sudo bpftrace -e 'tracepoint:syscalls:sys_enter_read { @reads[comm, args->fd] = count(); } interval:s:5 { print(@reads); clear(@reads); }' - 想关联文件路径？eBPF 里不能直接查
/proc/PID/fd/，得先抓出高频comm+fd组合，再人工用lsof -p PID或readlink /proc/PID/fd/FD_NUM反查 - 避免性能抖动：别在 tracepoint 里做字符串拷贝或大量
printf，聚合用@count类型即可 - 不兼容旧内核：5.10+ 才推荐用
struct file路径推导，之前版本建议专注 fd+comm 统计
inotifywait 只适合短期、低频、已知文件的监听
它不是审计工具，是事件通知机制，误报漏报多，仅适用于调试或看护极少数关键配置文件：
- 启动监听：
inotifywait -m -e access /etc/hosts 2>/dev/null，每次触发输出一行/etc/hosts ACCESS - 它依赖
IN_ACCESS事件，而该事件仅在 open(O_RDONLY) + 实际 read 后才发，mmap、sendfile、/proc 读取均不触发 - 多个进程并发读同一文件时，容易漏掉中间事件；轮询脚本（如每秒 cat 一次）会导致事件堆积或丢弃
- 无法得知 UID、PID、命令行，连是 root 还是普通用户都分不清
auditd 规则写错、bpftrace 权限不足、inotifywait 事件丢失——这些坑比想象中更常见。真正要回溯“谁读过什么”，必须接受：没有开箱即用的命令，只有提前部署的机制。
