加 --security-opt label=type:container_runtime_t 会导致容器启动失败，因该类型专用于 Podman 自身进程而非容器应用，违反最小权限原则且破坏隔离边界。
Podman 启动容器时加 --security-opt label=type:container_runtime_t 会怎样？
它不会让容器跑得更“安全”，也不会自动适配 SELinux 策略——相反，90% 的情况下会直接启动失败，报 permission denied 或 avc: denied 错误。
这个选项本质是强行覆盖容器进程的 SELinux 类型标签，把本该是 container_t 的进程硬设成 container_runtime_t。而 container_runtime_t 是专给 podman、conmon 这类运行时二进制本身用的类型，不是给容器里应用进程用的。
- SELinux 策略默认禁止
container_runtime_t类型进程执行网络绑定、挂载、读写容器卷等常见操作 - 即使你手动写策略放行，也会破坏容器隔离边界：该类型能访问宿主机 runtime 的 socket 和状态目录
- Podman 默认不加这个参数，就是因为它不符合容器最小权限原则
什么场景下真需要改 SELinux 类型？
极少数情况要显式指定类型，比如调试 SELinux 策略、或部署某些强依赖特定上下文的遗留服务（如某些政府/金融定制镜像要求 spc_t）。
但这时你应该用的是 container_t 的变体，而不是 container_runtime_t：
- 想放宽文件访问？用
--security-opt label=type:container_file_t（需配套策略） - 要跑特权级系统服务？考虑
--security-opt label=type:spc_t，但必须确认镜像已适配 - 调试时临时绕过限制？用
setenforce 0比硬塞错类型更可靠
--security-opt label=... 的参数格式和常见错误
SELinux 类型名必须完整、大小写敏感、末尾带 _t；中间不能有空格或非法字符。Podman 不做校验，传错就静默失败或触发 AVC 拒绝。
- 错误写法：
--security-opt label=type:container_runtime_t（末尾空格）→ 容器可能启动但 SELinux 上下文不生效 - 错误写法：
--security-opt label=type:container_runtime（缺_t）→ SELinux 忽略该标签，回退到默认container_t - 正确写法：
--security-opt label=type:container_t（虽冗余，但明确） - 验证是否生效：
podman exec -it <code>CONTAINER_IDps -Z，看首列是否匹配你设的类型
替代方案：比硬改类型更稳妥的做法
绝大多数你想通过改 SELinux 类型解决的问题，其实有更轻量、更可控的方式。
- 挂载宿主机路径时权限拒绝？加
:z或:Z后缀：-v /host/data:/app/data:z - 容器内无法写入卷？检查 volume 创建时的 SELinux 上下文，用
podman volume create -o label=type:container_file_t vol1 - 需要开放特定端口或能力？用
--cap-add、--sysctl或--network=host，而不是动类型 - 策略冲突频繁？用
ausearch -m avc -ts recent | audit2why查真实拒绝原因，再针对性调策略
SELinux 类型不是开关，是策略锚点。乱改类型就像把保险丝换成铜线——表面通了电，但下次过载就烧整个系统。
