必须用ausearch -k perm_change -i解析auditd日志，-i将数字uid/pid转为用户名和进程名，关键看comm、exe、auid字段；-f按路径匹配易失效，应优先用-k规则标签查询。
auditd 日志里怎么看清楚 chmod 是谁执行的
直接查 /var/log/audit/audit.log 原始日志几乎不可读——全是数字 UID、PID 和十六进制字段。必须用 ausearch + -i 解析，否则看不出用户、命令、路径。
-
ausearch -k perm_change -i：前提是规则用了-k perm_change，-i把 uid=1001 变成 username，把 pid=12345 变成实际进程名 - 如果没加
-i，你会看到comm="unknown"、exe="/proc/12345/exe (deleted)"，基本等于白查 - 关键字段优先看：
comm（触发命令，如chmod或bash）、exe（真实可执行路径，区分是否是恶意伪装的同名二进制）、auid（原始登录用户 ID，比uid更可靠，防 sudo 提权后丢失上下文） - 时间字段是
time->...，不是系统本地时间，而是自 epoch 起的秒数，ausearch --start today -i会自动转换
为什么 ausearch -f /path/to/file 经常查不到东西
-f 按文件路径匹配，但 auditd 日志里存的是 inode 层面的路径快照；如果目标文件被 mv 替换、硬链接访问或挂载点变更，-f 就会失效。更稳的方式是用 -k 关键字过滤。
- 规则里必须明确指定
-k myrule，查询时统一用ausearch -k myrule -i - 比如监控
/etc/ssh/sshd_config权限变更，规则写-w /etc/ssh/sshd_config -p a -k sshd_perm，查就用ausearch -k sshd_perm -i -
-f在软链接目标变动、rename 场景下极易漏事件；-k绑定的是规则本身，不依赖路径实时存在 - 若已用
-f查不到，立刻检查sudo auditctl -l是否真有对应规则加载，而不是只写了配置没 reload
chmod 日志里看不到完整命令行参数怎么办
auditd 默认不记录 argv（命令行参数），只记 comm 和 exe。想看到 chmod 644 /tmp/x 这种完整信息，得额外启用 execve 系统调用监控，且仅适用于 exec 类操作。
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- 普通
chmod命令本身是独立进程，comm="chmod"+exe="/usr/bin/chmod"已足够定位；但如果是 shell 内建命令（如 dash 的chmod）或脚本里拼接调用，就只能靠cwd和ppid向上追 - 要捕获参数，需加规则：
sudo auditctl -a always,exit -F arch=b64 -S execve -F exe=/usr/bin/chmod -k chmod_exec - 注意：
execve规则开销大，生产环境慎用；且它只抓“执行新进程”，不抓 libc 内部的fchmodat等直接系统调用（比如 Python 的os.chmod()） - 真正可靠的溯源链是：
comm→exe→auid→cwd→ppid（父进程 ID），必要时用ausearch -p <ppid> -i</ppid>往上查
auditd 没启用或规则没覆盖时，还能抢救吗
不能回溯，但可以交叉验证缩小嫌疑人范围。核心是确认变更发生的时间窗口，再查那个时段谁有权限、谁在线、谁跑过相关命令。
- 用
stat /path/to/file看Change时间（ctime），这是唯一可信的时间锚点 - 查那个时刻附近有没有 sudo 记录：
grep -a "chmod\|chown" /var/log/auth.log | awk '$3":"$4 > "06/07 14:20" && $3":"$4 （按实际时间调整） - 用
last -ai | awk '$5 ~ /([0-9]{1,3}\.){3}[0-9]{1,3}/ {print}'看远程登录 IP，比对登录时间与 ctime 是否重叠 - 检查 cron：
sudo grep -r "chmod\|chown" /etc/cron* /var/spool/cron/ 2>/dev/null，尤其注意 root 用户的定时任务
auditd 规则一旦没提前配，日志就不存在——所有“事后补救”都只是概率排查，不是证据链。最易被忽略的是：规则写了但没运行 augenrules --load，或者规则文件名没以 .rules 结尾导致被忽略。
