linux不记录chmod/chown历史，无内置日志；ctime仅反映元数据变更时间，无法追溯操作者、原始权限或命令上下文；审计需提前配置auditd或systemd-journald，事后无法补救。
Linux本身不记录 chmod 或 chown 的权限变更历史，没有内置日志功能来追踪“谁在什么时候把哪个文件的权限改成了多少”。所谓“查看权限递归变更生效记录”，本质上是在找间接证据或提前部署的审计手段。
为什么 chmod -R 没有执行日志
Linux内核和标准工具链（chmod、chown）默认不写操作日志——它们是无状态的原子操作。执行完就结束，不落盘、不通知、不归档。你运行 sudo chmod -R 755 /var/www/html，系统不会自动记下时间、UID、命令行参数或影响了哪些具体文件。
- 除非你手动加了
history或 shell 日志，否则命令本身只留在当前会话的history缓存里，且易被覆盖 -
ls -l只能显示当前权限，不能回溯“上次是什么” - 文件的
ctime（change time）虽会更新，但它反映的是元数据变更（含权限、所有者、链接数等），无法区分是 chmod 还是 chown 导致的，也无法还原原始值
stat 能看到什么？只能看 ctime，不是 audit log
对单个文件运行 stat filename，你会看到类似：
Access: 2026-07-05 14:22:01.123456789 +0800 Modify: 2026-07-05 14:22:01.123456789 +0800 Change: 2026-07-08 10:15:22.987654321 +0800
其中 Change 字段就是 ctime，它会在 chmod 后更新，但：
- 它不记录操作者、不记录旧权限、不记录命令上下文
- 递归操作后，所有被修改项的 ctime 都会变成相近时间点，但无法反推“哪些是目录、哪些是文件、是否跳过权限不足项”
- 如果你没提前保存快照，就永远丢失了变更前的状态
真要审计，得靠 auditd 或 systemd-journald 提前配置
生产环境若需追溯权限变更，必须主动启用审计机制，而不是事后补救：
- 用
auditctl监控chmod和chown系统调用：sudo auditctl -a always,exit -F arch=b64 -S chmod,fchmod,fchmodat -k perm_changesudo auditctl -a always,exit -F arch=b64 -S chown,fchown,fchownat -k perm_change - 日志查法：
sudo ausearch -k perm_change | aureport -f -i - systemd 系统可查
journalctl _COMM=chmod，但仅限于该命令被直接调用（不捕获find -exec chmod中的子进程） - 这些都要求 auditd 服务已启用且规则在变更发生前就加载——临时起意去查，基本为空
最现实的补救办法：用 find + stat 做快照比对
如果你现在怀疑某次递归操作已发生，但没留记录，唯一可行的“回溯”方式是依赖时间窗口和文件属性特征：
- 先确认大致操作时间（比如运维同事说“上午10点左右跑了 chmod”）
- 用
find /path -type f -newermt "2026-07-08 10:00" ! -newermt "2026-07-08 10:30" -ls找出那段时间内 ctime 变更的文件 - 再用
find /path -type d -perm 755 -ls和find /path -type f -perm 644 -ls看是否符合典型网站权限模式，辅助判断是否为人为批量设置 - 注意：这只能推测，不能证明；误判率高，尤其当系统有其他自动化任务时
真正关键的点在于：权限变更不可逆，日志不可追加——所有审计能力都必须在操作发生前就位。等出了问题再问“怎么查记录”，答案往往只剩一句：没有，除非你早开了 auditd。
