chcon 设置后 httpd 仍报 Permission denied，是因为它只修改文件标签而未更新 SELinux 策略许可、未注册永久上下文规则、也未确保进程域与布尔值匹配。
为什么 chcon 设置后 httpd 仍报 Permission denied？
SELinux 处于 enforcing 模式时，仅用 chcon 修改文件上下文往往不够——它只改了“标签”，但没告诉 SELinux “这个标签是否被策略允许用于 httpd 访问”。常见现象是：ls -Z 显示路径已设为 httpd_sys_content_t，setsebool -P httpd_read_user_content 1 也开了，但 tail -f /var/log/audit/audit.log | audit2why 仍提示 avc: denied { read }。
chcon 的局限：只改标签，不改策略许可
chcon 是纯客户端工具，它不修改 SELinux 策略规则，也不检查目标类型是否被 httpd_t 域授权访问。典型错误操作：
- 对整个
/srv/myapp执行chcon -Rt httpd_sys_content_t /srv/myapp，但策略里没声明httpd_t可读httpd_sys_content_t（其实默认是允许的，但自定义路径常落在非标准区域，如/opt或/home，其父目录可能带unconfined_u:object_r:default_t:s0，会触发 type enforcement 阻断） - 用
-u或-r参数硬改用户/角色，反而破坏 MLS/MCS 级别匹配 - 未用
-R递归，导致子目录或新生成文件仍为原始上下文
必须补上的三步：恢复、校验、放行
绕过 chcon 单点操作，走完整链路：
- 先用
restorecon -Rv /path/to/dir清除手工chcon的副作用，还原为策略默认上下文（避免混用导致 context 不一致） - 查当前路径应属什么类型：
seinfo -a file_type -x | grep httpd，确认httpd_sys_content_t确实存在且是目标类型 - 真正关键一步：用
semanage fcontext -a -t httpd_sys_content_t "/srv/myapp(/.*)?"注册永久上下文规则，再执行restorecon -Rv /srv/myapp生效——这才能确保新文件、重启后都保持正确类型 - 若仍拒绝，检查是否触发布尔值限制：
getsebool -a | grep httpd | grep read，特别注意httpd_can_network_connect（反向代理场景）、httpd_read_user_content（读/home下内容）等是否启用
nginx 用户要注意：SELinux 默认不认 nginx
CentOS/RHEL 自带策略只定义 httpd_t，而 nginx 进程默认运行在 unconfined_t 或 initrc_t 下，chcon 给文件打 httpd_sys_content_t 标签毫无意义——因为策略没给 nginx 进程授权读该类型。解决方式只有两个：
- 改 nginx 进程域：
semanage permissive -a nginx_t（临时宽容模式，不推荐生产） - 或更稳妥：用
semanage fcontext -a -t httpd_sys_content_t "/usr/share/nginx/html(/.*)?"+restorecon，并确保 nginx 配置中 root 路径严格落在 SELinux 已知受信路径内（如/usr/share/nginx/html），而非随意指向/opt/app - 验证进程域：
ps -eZ | grep nginx，看到system_u:system_r:httpd_t:s0才算真正接入 SELinux 策略链
自定义路径的 SELinux 适配，本质是让“路径上下文”“进程域”“布尔策略”三者对齐；漏掉任一环，chcon 就只是贴了个无效标签。
