Gitea 升级后报 203/EXEC：检查移动后二进制的 SELinux 标签

Gitea 二进制已经替换，systemd 启动却停在 status=203/EXEC，还没有进入应用运行阶段。在 Fedora 启用 SELinux enforcing、将新文件从 Gitea 数据目录移动到 /usr/local/bin/gitea 的升级流程中，应检查文件是否保留了不合适的安全标签。

这条路径出现在 1.24.3 升级到 1.25.5 的环境，但不能把所有 Gitea 203/EXEC 都归到 SELinux。程序路径、执行权限、挂载选项和解释器仍有各自的检查条件。

先核对实际执行的文件

查看完整 unit 和最早的执行错误，确认失败指向真实二进制，而不是字面变量或另一个旧路径。对已确认的安装路径做检查：

getenforce
ls -lZ -- /usr/local/bin/gitea
sudo restorecon -n -v /usr/local/bin/gitea

restorecon -n 只预览，不修改标签；-v 显示可能调整的内容。路径是该安装布局的例子，不能给不在这里的程序照抄。SELinux disabled 时，这项归因不成立；permissive 下通常记录而不阻断，也需要寻找实际拒绝层。

对照失败时间的审计记录，检查进程、文件和执行拒绝是否对应。原先的数字退出状态并不能证明具体标签类型，更不能替代这些证据。

移动文件不会总按目标路径重新标记

同一文件系统内的普通移动主要改变路径，文件原有属性可能保留；跨文件系统移动也会尝试复制扩展属性，其中包括 SELinux 上下文。不能假定放进 /usr/local/bin 后就自动获得该路径的默认标签。

权限位和 SELinux 标签分别起作用。chmod +x 解决不了已具有执行位的错误标签，chmod 777 还会无谓扩大修改权限。也不要给主机二进制套用容器 bind mount 的 :Z，或 Nginx 网络连接布尔值。

默认策略明确时，只修正目标文件

保存安装二进制、原标签与部署记录；确认目标路径应使用系统已有的默认策略，且预览变化符合部署要求后，由管理员执行：

sudo restorecon -v /usr/local/bin/gitea

这是标签修改，不是只读检查。不要递归重标整个数据目录，也不要无条件加 -F 去覆盖所有上下文字段。真正的自定义路径应先按本机策略安排窄范围、持久的 semanage fcontext 映射，再应用标签；不能凭另一台服务器的类型名称猜一个放行值。

升级脚本即使调用了 restorecon，也要检查实际标签和错误状态。带有 || true 的片段会掩盖该命令失败，脚本结束不等于修复已完成。

启动与业务检查都要通过

标签修正后，在维护窗口重启目标服务，确认不再发生同一路径的 EXEC 拒绝，并检查 Gitea 页面、登录和正常仓库操作。若接下来出现配置或数据库错误，应保留新日志，按新的故障阶段处理。

没有相应标签差异或审计依据时，回到noexec 挂载导致执行失败、服务工作目录访问失败等不同条件。200/CHDIR 与 203/EXEC 不能当作同一个启动阶段。

回退旧程序也要按其正确安装路径恢复标签，并遵守 Gitea 版本与数据库兼容要求。二进制备份不能单独保证数据库可降级；已有数据应依据升级前的正式备份恢复流程处理。保留 SELinux enforcing，避免用关闭策略掩盖部署标签问题。