getenforce仅返回内核当前运行模式（enforcing/permissive/disabled），不读取/etc/selinux/config配置，故无法判断永久设置；sestatus则同时显示当前模式与配置文件设定模式，是验证是否永久生效的可靠依据。
getenforce 命令只返回当前内核模式，不查配置文件
getenforce 是最轻量、最直接的方式，但它只读取内核当前运行时的 SELinux 模式，不关心 /etc/selinux/config 里写了什么。执行后静默输出一行：Enforcing、Permissive 或 Disabled。
常见错误是误以为运行过 setenforce 0 就等于“关了 SELinux”——其实只是临时切到宽容模式，重启后立刻回弹。所以单靠 getenforce 无法判断是否“永久生效”。
适合场景：
- 脚本中做条件判断（如
if [ "$(getenforce)" = "Enforcing" ]; then ...） - 故障排查时快速确认策略是否正在阻断操作
- 验证
setenforce是否已即时生效
sestatus 显示运行态 + 配置态双维度信息
sestatus 输出更完整，关键字段有两组：Current mode（当前内核实际模式）和 Mode from config file（配置文件设定的默认模式）。这两者不一致很常见——比如配置文件写的是 enforcing，但你刚用 setenforce 0 切到了 Permissive。
注意：SELinux status: disabled 表示完全未加载，此时 /sys/fs/selinux 通常不可访问；而 Current mode: disabled 不会出现，因为 disabled 状态下 sestatus 可能直接报错或不显示该字段。
容易踩的坑：
- 没装
policycoreutils包时，sestatus命令不存在，需先yum install policycoreutils或dnf install policycoreutils - 某些精简镜像（如部分 Docker base 镜像）压根没启用 SELinux，
sestatus返回空或报错，此时应优先检查/etc/selinux/config
/etc/selinux/config 决定重启后的默认行为
这个文件才是“永久开关”的唯一依据。核心就看这一行：SELINUX=enforcing（或 permissive / disabled）。它不控制当前状态，只管下次启动。
修改后必须重启才生效——setenforce 对 disabled 状态无效，也无法从 disabled 临时切回 enforcing。这是硬限制。
额外注意点：
-
SELINUXTYPE=targeted是主流策略类型，改它不会影响模式，但换mls可能导致服务启动失败 - 编辑前建议备份：
cp /etc/selinux/config /etc/selinux/config.bak - 若系统启动卡在 SELinux relabel 阶段，可临时加内核参数
selinux=0进 GRUB 启动，再修复配置
为什么 setenforce 0 后 getenforce 显示 Permissive 却还是报权限错？
因为 setenforce 0 只切换模式，不修复上下文标签。如果文件或进程的 SELinux 上下文（如 system_u:object_r:httpd_sys_content_t:s0）本身被破坏或不匹配，即使在 Permissive 模式下，某些服务（如 httpd、sshd）仍会因内部检查失败而拒绝启动。
这时要结合 ls -Z 查文件上下文、ps -Z 查进程上下文，并用 restorecon 或 chcon 修复。单纯依赖 setenforce 0 是治标不治本。
真正复杂的点在于：SELinux 的问题从来不是“开或关”，而是“策略是否匹配当前运行时状态+上下文是否正确”。忽略上下文，等于只拧松了螺丝，没拆掉卡住的零件。
