GitHub Actions upload-artifact 在非特权容器中的权限问题分析

GitHub Actions 的 upload-artifact 插件是 CI/CD 流程中常用的工具，用于在工作流运行过程中上传构建产物。然而，在最新版本(v4)中，当工作流运行在非特权容器环境时，会出现权限问题导致工作流失败。

问题现象

当用户尝试在基于 busybox 的非特权容器环境中使用 upload-artifact@v4 上传文件时，会遇到 EACCES 权限拒绝错误。具体表现为插件能够成功上传文件，但在最后阶段尝试写入输出文件时失败。

错误信息显示系统无法访问临时目录下的输出命令文件，这表明插件在容器内部执行时缺乏必要的文件系统权限。值得注意的是，同样的工作流在使用 v3 版本时可以正常运行。

技术背景分析

upload-artifact 插件从 v3 升级到 v4 的过程中，底层实现发生了重要变化：

1. Node.js 版本升级：v3 基于 Node.js 16，而 v4 升级到了 Node.js 20。Node.js 16 已进入生命周期结束状态，继续使用存在安全风险。

2. 权限模型变化：新版本可能采用了更严格的权限检查机制，或者改变了临时文件的处理方式。

3. 容器安全限制：在非特权容器环境中，默认用户通常不是 root，且文件系统访问受到严格限制。

解决方案探讨

对于遇到此问题的用户，有以下几种解决方案：

1. 调整容器权限：虽然最初认为联邦安全要求禁止使用 root 用户，但进一步分析表明，安全要求主要针对容器平台权限而非容器内部用户。因此，可以在容器内部使用 root 用户运行。

2. 修改文件权限：在工作流步骤中显式设置文件和目录的适当权限，确保 upload-artifact 插件能够访问所需资源。

3. 使用替代路径：将构建产物放在容器内可写的标准位置，而非临时目录。

4. 等待官方修复：虽然类似问题在其他 GitHub Actions 插件中已存在较长时间，但用户仍可期待官方在未来版本中提供解决方案。

最佳实践建议

对于需要在严格安全环境下使用 GitHub Actions 的团队，建议：

1. 全面评估容器安全需求，区分容器平台权限和容器内部权限。

2. 在 CI/CD 流水线设计阶段就考虑文件权限问题，避免后期调整。

3. 对于关键工作流，进行充分测试后再升级插件版本。

4. 考虑使用自定义容器镜像，预先配置好所需权限和环境。

这个问题反映了在现代化 CI/CD 流程中平衡安全性和功能性的挑战，开发团队需要根据具体安全要求和业务需求选择最适合的解决方案。