auditctl监控uid 1000用户所有文件访问需用-a always,exit -f arch=b64 -s open,openat,creat,unlink,unlinkat -f auid=1000 -k user_1000_file_ops，因-w不支持auid字段；auid记录初始登录uid，比uid/euid更可靠溯源。
auditctl 怎么监控 UID 1000 用户的所有文件访问
直接用 -F auid=1000 过滤，但必须搭配系统调用规则（-a），不能用 -w 路径监控——因为 -w 不支持 auid 字段。常见错误是写成 auditctl -w /home/test -p rwxa -F auid=1000，这会静默失败，规则不生效。
正确做法是监听 open、openat、creat、unlink 等关键系统调用，并限定架构和 UID：
sudo auditctl -a always,exit -F arch=b64 -S open,openat,creat,unlink,unlinkat -F auid=1000 -k user_1000_file_ops
-
-F arch=b64必须显式指定，否则 64 位系统上可能漏掉部分调用 - 如果机器同时跑 32 位程序，得额外加一条
-F arch=b32规则 -
auid是登录时确定的审计 UID，不会随su或sudo改变，比uid更可靠
为什么用 auid 而不是 uid 或 euid
auid 记录的是用户首次登录会话的 UID，哪怕后续用 sudo -u nobody cat /etc/shadow，日志里 auid 仍是原始登录用户的 ID；而 uid 是当前进程有效 UID，euid 是有效用户 ID，两者在提权后都会变，无法追溯真实操作者。
典型误判场景：
- 运维用普通账号登录，再
sudo su -切 root 后修改配置文件 →uid和euid都是 0，但auid仍是 1000 - 脚本中调用
setuid程序 →uid变了，auid不变
所以审计“谁干的”，必须盯 auid，不是 uid。
如何验证规则是否捕获到目标用户行为
别只等真实操作，用 ausearch 主动触发并查日志：
sudo -u testuser touch /tmp/audit_test && sudo ausearch -k user_1000_file_ops -i | grep "auid=1000"
关键检查点：
- 输出中必须有
auid=1000，且comm字段为touch，name为/tmp/audit_test - 如果没结果，先确认
testuser的 UID 确实是 1000：id -u testuser - 再检查规则是否加载：
sudo auditctl -l | grep user_1000 - 注意：
ausearch -k默认只查最近 24 小时，加-ts today更稳妥
持久化规则时要注意 augenrules 的编译顺序
把规则写进 /etc/audit/rules.d/ 下的 .rules 文件后，必须用 augenrules --load，不能直接 systemctl restart auditd——后者只会重载 /etc/audit/audit.rules，而忽略 rules.d/ 目录下分散的文件。
更隐蔽的坑：
- 文件名必须以数字开头（如
10-user-audit.rules），否则augenrules会跳过 - 多条规则若涉及同一系统调用（比如都含
open），augenrules会合并成一行，但字段顺序错乱可能导致过滤失效 - 建议每条规则单独一行，用
#注释说明用途，避免后期维护时搞混auid和uid的使用意图
真正难的不是加规则，而是确保 auid 在所有登录路径（SSH、console、cron job）下都被正确继承，以及日志量暴增时能快速过滤出有效事件——这两点没压测过就上线，容易在出事时找不到线索。
