selinux权限冲突表现为静默拦截而非“权限不够”错误，需通过getenforce确认状态、setenforce临时切宽容模式验证，并用ausearch查audit.log中的avc拒绝记录，结合audit2why解析原因、sealert生成结构化诊断。
Linux 系统中权限不足被拦截的操作，不一定都表现为“Permission denied”报错——尤其是 SELinux 或 systemd 的安全机制介入时，常为静默拒绝，只留日志痕迹。关键不是看错误提示，而是查它拦了什么、为什么拦、谁被拦住了。
先确认是不是 SELinux 在拦截
SELinux 是最常导致“没报错却执行失败”的元凶，它不抛异常，只记审计日志：
- 运行 sudo getenforce：返回 Enforcing 才说明它正在强制拦截；若为 Permissive，只记录不阻止；Disabled 则完全不生效
- 临时切宽容模式验证：sudo setenforce 0，再重试出问题的操作（如启动服务、读配置文件）。若立刻成功，基本锁定是 SELinux 拦截
- 测试完务必恢复：sudo setenforce 1
查 SELinux 拒绝记录（audit.log）
/var/log/audit/audit.log 是原始证据库，但别直接 grep ——容易漏字段。推荐用专用工具：
- 查最近所有拒绝：sudo ausearch -m avc -ts recent
- 聚焦某个进程（如 nginx）：sudo ausearch -m avc -ts recent -c nginx
- 定位某路径（如 /etc/myapp/conf）：sudo ausearch -m avc -ts recent -f /etc/myapp/conf
- 每条 AVC 记录含四要素：scontext（进程上下文）、tcontext（目标文件上下文）、tclass（对象类型，如 file/dir）、perm（被拒操作，如 read/write/exec）
把日志翻译成可读原因
原始 AVC 日志对人不友好，用 audit2why 解析：
- sudo ausearch -m avc -ts recent | audit2why
- 它会明确告诉你缺哪条规则，例如：“Missing allow httpd_t var_log_t:file write”，或指出类型不匹配：“tcontext type user_home_t does not match expected type httpd_sys_content_t”
- 还可配合 sealert -a /var/log/audit/audit.log 生成结构化诊断建议
排除 SELinux 后，再查常规权限日志
如果确认不是 SELinux，再排查传统权限问题，重点看这些日志：
- /var/log/secure（RHEL/CentOS）或 /var/log/auth.log（Debian/Ubuntu）：记录 sudo 失败、su 被拒、SSH 权限拒绝等认证类权限错误
- /var/log/messages 或 /var/log/syslog：服务启动失败时，常有类似 “Failed to start xyz.service: Permission denied” 的提示
- 用 sudo journalctl -u servicename --since "2 hours ago" 查 systemd 服务的完整启动上下文，有时比文件日志更及时、更全
