GitHub Actions 未正确检测 SELinux 相关问题。

在处理 geerlingguy.nginx 问题 #265 过程中,我发现了一个无法通过 GitHub Actions 正确测试的问题,而实际上这只是冰山一角。使用 GitHub Actions,即使在运行 Rocky 9 容器中的测试中,由于它运行在 Ubuntu 服务器上,而非使用 SELinux,而是使用 AppArmor,因此无法看到由于 SELinux 导致的问题。这是因为内核本身没有启用 SELinux 支持,而容器依赖于内核来实现此功能。一个例子是,当我们使用 -t 选项运行 nginx,以验证生成的配置文件,然后将其复制到最终位置时,nginx 会创建一个错误的 SELinux 文件上下文的 PID 文件。由于 PID 文件是使用错误的上下文创建的,因此当 geerlingguy.nginx 在角色中运行下一个任务时,nginx 尝试打开 PID 文件,但被 SELinux 根据设计拒绝,并且 nginx 无法启动。但是,在失败中,文件被删除,下次尝试启动 nginx 时,启动成功。如果 SELinux 处于强制模式,则测试将会捕获到此问题,但 GitHub Actions 将不会,因为缺少了此功能。不幸的是,正如所指出的那样,这只是冰山一角,就测试而言。虽然可以编写测试来检查文件权限和 SELinux 文件上下文等问题,但由于文件上下文是 Linux 内核和文件系统(如 extfs 和 xfs)的核心,对于这种情况的真正测试将是将其运行在 SELinux 处于强制模式的环境中,在这种情况下,任务将在开发测试期间被认为失败。不幸的是,由于其设计方式,目前无法在 GitHub 中这样做,因为要在 Ubuntu 上安装 SELinux,您必须重启机器才能激活它,而这反过来导致 GitHub 回收 VM。也许,如果我们中有足够多的人将此问题作为启用 SELinux 的 VM 镜像的请求,例如运行 Rocky 9 的镜像,或者甚至可以提供一个正确配置的基于 Ubuntu 的镜像。就目前而言,测试此情况或任何其他与 SELinux 相关的设置的唯一方法是在开发者自费提供的 VM 或 bare metal 服务器上运行测试。由于这种情况如何影响整个操作系统分支,并涉及一个广泛用于全世界各地系统安全的功能,例如在大学、联邦机构和实验室,甚至在金融领域,因此这可能值得在下一次更新中将至少突出显示的警告(如果不是添加更强的警告,因为它涉及安全性)添加到第 13 章,以及在 Errata 页面上同样突出显示的错误。令人遗憾的是,即使电子书格式也使用黑白图标来表示警告,而不是使用绿色、黄色(或橙色)和红色等颜色的图标,以使其更加突出。