getenforce 返回 Permissive 但访问仍被拒绝，根本原因是 SELinux 未真正生效于当前上下文，需用 sestatus -b、ps -Z、/sys/fs/selinux/enforce 等交叉验证；Permissive 模式下 avc denied 仅记录不拦截，操作失败通常源于 DAC 权限、防火墙或服务配置。
getenforce 返回 Permissive 却仍被拒绝？先确认是否真在 Permissive 模式
很多情况下 getenforce 显示 Permissive，但实际访问仍被拒绝，根本原因往往是 SELinux 并未真正生效于当前上下文——比如容器、systemd 服务或特定用户会话中 SELinux 策略可能被绕过或未加载。用以下命令交叉验证：
-
sestatus -b查看policy booleans是否启用（尤其关注allow_xserver、httpd_can_network_connect等相关项） -
ps -Z | grep your_process确认目标进程的 SELinux 上下文是否为预期值（如system_u:system_r:httpd_t:s0），而非unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 -
cat /sys/fs/selinux/enforce—— 返回0才是真正的 Permissive；返回1表示 enforce 被硬编码开启，getenforce可能被缓存或误读
boolean 值显示 on 但不生效？检查策略模块加载状态与域限制
SELinux boolean 不是全局开关，它只对**已加载且声明依赖该 boolean 的策略模块**起作用。常见陷阱是：你执行了 setsebool httpd_can_network_connect on，但系统用的是 nginx，而默认 nginx 策略没引用这个 boolean（它用的是 nginx_can_network_connect 或压根没定义）。
- 用
sesearch -b httpd_can_network_connect查看该 boolean 实际控制哪些规则；若无输出，说明当前策略未声明它 - 用
seinfo -a bool -x列出所有可用 boolean，并确认其值是否真为on（注意：临时设置需加-P才持久） - 某些 boolean（如
container_manage_cgroup）仅对特定域（如container_t）有效，对unconfined_service_t无效
audit.log 里出现 avc denied，但 getenforce 是 Permissive？那是 audit 日志在“记账”，不是“拦截”
Permissive 模式下 SELinux **不阻止操作，但会记录所有本该拒绝的行为到 /var/log/audit/audit.log**。所以看到 avc: denied 日志 ≠ 操作失败，只是告诉你“如果现在是 Enforcing，这里就会被拦”。容易误判为配置失效。
- 用
ausearch -m avc -ts recent | audit2why解析日志含义，确认是否真有阻断发生 - 若操作确实失败（如
Connection refused或Permission denied），问题大概率不在 SELinux，而是文件 DAC 权限、端口占用、防火墙（firewalld/nftables）或服务自身配置 - Permissive 下仍需确保
setroubleshoot服务运行，否则sealert -a /var/log/audit/audit.log无法生成可读建议
systemd 服务启动时 boolean 生效异常？检查服务单元的 SELinux 上下文继承
systemd 启动的服务默认使用 system_u:system_r:init_t:s0 或其派生域（如 httpd_t），但若服务用了 DynamicUser=yes 或 ProtectSystem=strict，SELinux 上下文可能被重置为 unconfined_service_t，导致 boolean 失效。
- 用
systemctl show --property=SELinuxContext your.service查看服务声明的上下文（为空则继承默认） - 手动指定：在 service 文件中加
SELinuxContext=system_u:system_r:httpd_t:s0（需策略支持） - 更稳妥做法：用
semanage permissive -a httpd_t临时将整个域设为 permissive，排除 boolean 细粒度控制干扰
getenforce 的输出更关键。 
