科技 · 实用指南
systemd 显示 status=203/EXEC？改权限前先审计失败的 execve 路径
203/EXEC 表示服务管理器无法执行配置的进程。应根据日志的精确原因区分目标或解释器缺失、格式无效、路径/挂载拒绝与强制访问控制，再做修改。
systemd 单元以 code=exited、status=203/EXEC 结束时，通常还没进入应用逻辑。systemd 将 203 定义为 EXIT_EXEC，即 execve 系统调用失败。这个结论缩小了范围，却不能自动指出是哪个路径、解释器、挂载规则或安全策略造成失败。
不要先 chmod 777、套一层 shell 或关闭 SELinux。先保留实际加载的单元以及第一条“Failed at step EXEC”日志，再沿服务真正需要跨过的执行边界审计命令。
1. 保留真正失败的命令
运行 systemctl cat UNIT，以及 systemctl show -p ExecStart -p User -p Group -p RootDirectory -p RootImage UNIT。读取本次启动中第一条 EXEC 失败日志并保存其路径与尾部原因。只有单元定义实际修改后才需要 daemon-reload。
把 ExecStart 当作 systemd 语法而不是交互式 shell。管道、重定向和 shell 展开只有在明确设计需要时才应使用显式 shell。systemd #23235 证明把 ${APP} 放在可执行文件位置会产生 203/EXEC。
2. 按日志原因映射 execve 分支
遇到“No such file or directory”，先用 readlink -f、stat 检查目标，再用 head -n1 或 readelf -l 检查解释器。execve 文档明确指出 ENOENT 也包括脚本解释器或 ELF 解释器不存在；CRLF 还可能把隐藏回车带进 shebang。
遇到“Permission denied”，用 namei -l 检查目标和解释器的每级目录，再用 findmnt -T PATH -o TARGET,FSTYPE,OPTIONS 查看 noexec。遇到“Exec format error”，用 file 与 readelf -h 核对格式和架构。命令只收集证据，不等于授权改权限、标签或挂载。
3. 检查服务上下文，而不只检查 shell
确认有效 User、Group，并只在该身份下做无害的路径测试。若设置了 RootDirectory 或 RootImage，可执行文件及其依赖必须在新根中；私有或保护性文件系统设置也可能让服务看到与宿主 shell 不同的路径。
若日志是 EACCES 且普通权限正常，使用发行版支持的审计工具查看近期策略记录。Red Hat 记录了 init_t 对 default_t、user_home_t、nfs_t 或 cifs_t 执行被 AVC 拒绝并表现为 203/EXEC 的案例。AVC 说明应谨慎纠正标签或策略，而不是全局关闭强制模式。
4. 只修复已经证明的原因
只有在分支被证明后，才精确修正路径、解释器、换行、执行位、父目录搜索权限、挂载位置、架构、命名空间可见性或策略标签。不要 chmod 777；它无法修复缺失解释器、错误架构、noexec 或策略转换。
ExecStart 应优先使用直接绝对路径。增加 /bin/bash 可能绕过某个脚本执行分支，却隐藏原始 shebang 问题并改变 execve 启动的文件。真正需要 shell 时，应明确按 shell 语法设计和引用，而不是把它当万能修复。
5. 证明服务跨过了执行边界
做完最小修改后，只有单元定义变化才运行 daemon-reload，然后只启动一次并读取新日志。203/EXEC 消失只说明执行边界已跨过，应用仍可能因自己的错误码失败；还要核对 ActiveState、SubState、ExecMainCode 和 ExecMainStatus。
记录原始日志原因、唯一改动和修改后状态。若 203 仍在，回到新的第一条 EXEC 日志，不要叠加更多改动。若路径或策略属于软件包服务、二进制来源不明，或修复会削弱安全边界，应停止并升级处理。
