RFC: 现代无权限的 Guix 守护进程配置的危险

作者: hebasto创建于 2026年9月13日更新于 2026年9月17日

标签BrainstormingBuild system

根据 Guix 的文档，配置 Guix 守护进程有两种方法：

以 "root" 权限运行 guix-daemon，让它以不具有特权的用户身份运行构建进程，这些用户来自构建用户池中…。

以单独的不具有特权的用户运行 guix-daemon，依赖 Linux 的不具有特权的用户命名空间功能来设置隔离的环境…。遗憾的是，这两种配置产生了明显不同的构建环境。因此，在不具有特权的守护进程上，一些包的测试套件失败。其中一些包是我们 Guix 环境的依赖项。例如，以下是 Python-distlib 的测试失败：

=================================== FAILURES ===================================
_______________________ FileOpsTestCase.test_is_writable _______________________

self = <test_util.FileOpsTestCase testMethod=test_is_writable>

def test_is_writable(self):
  sd = 'subdir'
  ssd = 'subsubdir'
  path = os.path.join(self.workdir, sd, ssd)
  os.makedirs(path)
  path = os.path.join(path, 'test')
  self.assertTrue(self.fileop.is_writable(path))
  if os.name == 'posix':
>           self.assertFalse(self.fileop.is_writable('/etc'))
E           AssertionError: True is not false
tests/test_util.py:721: AssertionError

具有不具有特权的守护进程的用户在本地构建依赖项而不是替换它们时，无论是通过传递 --no-substitutes 还是因为他们的平台上不存在替换项（例如，在 RISC-V 系统上），都会遇到此类错误。在 x86_64 和 aarch64 上，问题被替换项掩盖了，这些替换项是在 Guix 的构建农场上使用具有特权的守护进程构建的。尽管上游已知此类失败，但我们也应在 Bitcoin Core 项目层面上解决此问题。以下是一些可能的方法：

提供一个 shell 脚本，检测 Guix 守护进程配置并警告关于不具有特权的守护进程。
文档一个从不具有特权的守护进程到具有特权的守护进程的迁移路径（请注意，Guix 文档只记录了相反方向的迁移）。

内容来源: bitcoin/bitcoin

查看 GitHub 原文在 GitHub 查看讨论