SELinux拦截导致程序失败需三步闭环处理：查拒绝日志、析上下文类型、修安全标签；禁用SELinux属临时绕过，不可取。
统信UOS中程序因SELinux策略拦截而无法启动或运行失败，必须通过查看拒绝日志、识别上下文类型、修复安全标签三步闭环处理，不能仅靠关闭SELinux临时绕过。
确认SELinux是否为根本原因
执行getenforce命令，输出为Enforcing才说明SELinux正在生效并可能造成拦截；若为Permissive或Disabled，则问题与SELinux无关，需转向排查传统权限、AppArmor或服务配置。
检查系统日志是否存在AVC拒绝记录：sudo grep "avc: denied" /var/log/audit/audit.log | tail -10。没有匹配结果，说明SELinux未触发拦截，无需继续本流程。
【必须用audit.log而非messages】——/var/log/messages仅记录摘要，丢失关键的scontext/tcontext字段，无法定位具体进程与资源类型关系。
从日志提取关键诊断信息
找到一条典型AVC拒绝行，例如：avc: denied { read } for pid=1234 comm="nginx" name="config.json" dev="sda1" ino=5678 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:default_t:s0 tclass=file
从中提取三个核心字段：
• scontext（源上下文）：httpd_t，即nginx进程的类型；
• tcontext（目标上下文）：default_t，即被拒绝访问的文件类型；
• tclass（目标类别）：file，说明是普通文件访问。
重点比对tcontext是否为default_t、unconfined_t或etc_runtime_t等非标准类型——这些全是异常信号，表明该文件未被SELinux策略覆盖，后续所有同类访问都会被拒。
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
修复文件或目录的安全上下文
方法一：临时修复（仅当前会话有效）
执行sudo chcon -t httpd_sys_content_t /var/www/html/config.json。这一步操作起来很简单，直接把路径和类型填对就行。但注意：【chcon修改不持久】——系统更新、restorecon重刷、甚至某些软件包重装后，上下文会被自动还原，仅适合紧急验证。
方法二：永久修复（推荐）
第一步：用semanage注册新规则：sudo semanage fcontext -a -t httpd_sys_content_t "/var/www/html(/.*)?"。
第二步：强制刷新整个目录树的上下文：sudo restorecon -Rv /var/www/html。
第三步：验证结果：ls -Z /var/www/html/config.json，确认输出中第三段已变为httpd_sys_content_t。
方法三：批量修正default_t异常
若ls -ZR /opt/app | head -15中大量出现default_t，执行：sudo semanage fcontext -a -t bin_t "/opt/app(/.*)?" → sudo restorecon -Rv /opt/app。这能一次性解决整个应用目录的标签缺失问题，避免逐个文件修复。
启用必要SELinux布尔值
某些功能默认被禁用，需打开对应开关。例如Nginx需读取用户主目录下的站点文件，要执行：sudo setsebool -P httpd_read_user_content 1。
【-P参数不可省略】——不加-P只能临时生效，重启后恢复原状，等于白设。
查看全部可用布尔值及其当前状态：getsebool -a | grep httpd。重点关注带read、exec、connect字样的条目，它们往往对应实际业务所需的最小权限。
验证修复效果
重启对应服务：sudo systemctl restart nginx。
再次尝试触发原报错操作，如curl访问页面或执行脚本。
若仍失败，立即执行sudo ausearch -m avc -ts recent | audit2why，该命令会将最新拒绝事件直译成可执行的修复建议，包括缺失的布尔值或应设的上下文类型。
