selinux拒绝访问时ls -z显示?或空字段，说明文件无上下文导致默认拒绝；需用matchpathcon查默认上下文、chcon临时标记、semanage fcontext+restorecon永久设置。
SELinux 拒绝访问时，ls -Z 看不见上下文怎么办
不是所有文件都自动打上 SELinux 上下文，尤其手动创建或从外部挂载的文件（比如 /mnt 下的 NTFS 分区、docker 卷、临时解压包），ls -Z 会显示 ? 或空字段。这时 SELinux 实际没生效，但你误以为是策略拦截——其实是“无上下文 → 默认拒绝”。
- 先确认是否真有上下文：
ls -Z /path/to/file，若第二列为空或为?，说明未标记 - 用
matchpathcon /path/to/file查看该路径本应匹配的默认上下文（基于/etc/selinux/targeted/contexts/files/file_contexts） - 手动打标：比如修复 Web 目录，运行
chcon -t httpd_sys_content_t /var/www/html/index.html - 永久生效要加
-R并用semanage fcontext注册规则，否则重启或restorecon会回退
avc: denied 日志里 type 不匹配，怎么快速定位策略模块
SELinux 错误日志里的 avc: denied 行会列出 scontext（源类型）、tcontext（目标类型）、tclass（对象类）和 perm（权限），但直接搜不到对应策略——因为策略按模块组织，不是按单条拒绝写死的。
- 用
ausearch -m avc -ts recent | audit2why把拒绝事件转成自然语言解释，它会提示“需要启用httpd_can_network_connect布尔值”或“需加载myapp模块” - 查已加载模块：
semodule -l | grep myapp；查模块含哪些规则：sesearch -A -s httpd_t -t port_t -c tcp_socket - 别直接改
/etc/selinux/targeted/policy/policy.*文件——那是编译产物，改了也没用 - 自定义策略必须用
audit2allow -a -M myapp生成 .te + .pp，再semodule -i myapp.pp
修改布尔值后服务仍失败，setsebool 缺少 -P 参数
setsebool httpd_can_network_connect on 只影响当前运行时，重启后失效。很多用户试过一次“好像好了”，但机器重启或服务重载后又报错，误以为是策略没生效。
- 务必加
-P：例如setsebool -P httpd_can_network_connect on，否则重启 SELinux 策略模块时还原为默认值 - 布尔值变更不触发服务自动重载，apache/nginx 需手动
systemctl restart httpd - 某些布尔值（如
container_manage_cgroup）依赖内核支持，旧系统可能根本不可设，getsebool显示Permission denied就是这个原因 - 生产环境慎用
setsebool -P selinuxuser_execheap on这类高危开关，它绕过内存执行保护
容器里 SELinux 上下文被覆盖，:z 和 :Z 的区别很关键
Docker/podman 启动容器时挂载宿主机目录，默认不继承 SELinux 上下文。用错标签会导致容器进程无法读写，或反过来让容器突破宿主机策略限制。
-
-v /host/data:/container/data:z：自动为宿主机路径设置共享上下文（container_file_t），多个容器可同时读写，但安全性较低 -
-v /host/data:/container/data:Z：设置专有上下文（container_file_t:s0:c1,c2），隔离性强，但其他容器或宿主机进程默认无法访问 - 不用
:z/:Z？那挂载点保持宿主机原始上下文，容器进程类型（如container_t）大概率无权访问（比如宿主机是admin_home_t） - kubernetes 中对应
securityContext.seLinuxOptions，不能只靠 Pod 注解，得配合节点 SELinux 策略模块
SELinux 文件控制真正卡住人的地方，从来不是“怎么开”，而是“谁在管”——上下文归属、策略模块加载状态、布尔值持久化、容器挂载语义，四个环节任意一个断掉，ls -Z 和 ausearch 就会给出相互矛盾的线索。