CentOS 7.9 上自建服务被 SELinux 拦住，按提示用 audit2allow -a -M myapp 生成并 semodule -i 装上了，重启服务后 audit.log 里同样的 avc denied 还在刷，进程仍然读不到目录。
一开始怀疑是「服务进程的域是自定义的，模块里没有对应的 allow 规则」，查了一圈，方向不对。
排查方向其实有限，先把可能性排一排。audit2allow 只取了当前日志里的部分记录，策略覆盖不全。还有一种是生成策略用的类型是 unconfined_service_t，装上去对实际域不生效。
另外，auditd 的日志被限流，前面的关键记录已经丢了。
动手时先把最近的完整 avc 记录导出来
ausearch -m avc -ts today | audit2allow -m myapp_v2 > myapp_v2.te然后确认进程所在的实际域
ps -eZ | grep myapp再往下按真实域重新生成并安装模块
checkmodule -M -m -o myapp_v2.mod myapp_v2.te && semodule_package -o myapp_v2.pp -m myapp_v2.mod && semodule -i myapp_v2.pp剩下的就是清掉旧模块避免规则打架
semodule -r myapp && semodule -l | grep myapp别只看报错消失，验证要多做一步。重启服务后 ausearch 里不再出现新的 avc denied，服务能正常读写目标目录，getenforce 仍是 Enforcing。
补一句。audit2allow 生成的是宽泛规则，生产环境要人工收敛到最小权限；装模块前先 semodule -l 看看有没有重名的旧版本。线上能稳定复现的问题都不算难，难的是只在大流量下才出现的那种。