无根容器

无根容器指的是非特权用户创建、运行和管理容器的能力。这个术语还包括围绕容器的各种工具，这些工具也可以作为非特权用户运行。这个网站的目标是将所有需要解决的未决问题和悬而未决的异议编入目录，以便让我们更接近无根容器。

在此上下文中的“非特权用户”指的是没有任何管理权限的用户，并且“没有得到管理员的好感”(换句话说，他们没有能力要求授予他们更多的特权，也没有能力要求安装软件包)。在此上下文中，“非特权用户”指的是没有任何管理权限的用户，并且“没有得到管理员的好感”(换句话说，他们没有能力要求授予他们更多的特权，也没有能力要求安装软件包)。

(O1)在他们的本地机器上创建、修改、分发和提取容器映像，以便他们可以通过(O0)运行所述容器映像。

(O2)在其本地计算机(有效的单节点群集)或通常能够与其通信并运行非特权程序的一组计算机上创建、管理和使用容器协调器。

虽然安全性不是该项目的主要目标(目标是支持用户)，但其目的是为了促进该项目所需的任何内核级改进都将涉及到与Linux Container Hardning Project的合作。我们希望最终的结果是无根容器既安全又有用，从而允许企业支持容器的这种使用。

这是一份活生生的文件，由人类维护。如果您希望在此列表中添加更多条目，或更新特定部分，请打开一个空请求。

支持模拟常规无根容器中不允许的系统调用。(例如，setgroup(2)、seteuid(2)、chown(2)…)。也就是说，让APT和YUM去工作。

支持在标准容器运行时中设置检查点和恢复容器。这与“标准化容器运行时”要求是分开的，因为它是一个辅助特性，是一个更一般的问题。

在编排引擎的容器运行时中支持无根容器。本文中的“容器运行时”包含的功能和任务比技术上精确的定义所包含的功能和任务要多。

为用户编写一些关于如何使用无根容器的文档。如果我们对Jessie令人敬畏的dockerfile repo，但是使用无根容器有一些寓言，那就太好了(她实际上也使用它们，但是一些更具描述性的文档会真的很有帮助)。

Open Container Initiative的运行时规范runc的实际实现支持开箱即用的无根容器。主要限制如下：

一般情况下不支持cgroup，因为在内核端，没有实现无特权的子树管理。主机cgroup装载有一个新的ns委派装载选项(在您创建cgroup命名空间时，它允许cgroupv2的子树委派)，但是由于runc既不支持cgroupv2，也不支持cgroup命名空间，因此此功能目前对我们没有用处。但是，如果系统配置为允许用户使用cgroup，那么最近的runc可以随意使用cgroup(有关如何配置这样的系统的示例，请参见lxcfs的PAM模块)。

CRIU支持非特权转储(检查点)，但是不支持恢复，并且检查点方面在无根容器的上下文中没有经过很好的测试。

在大多数情况下不使用网络名称空间，因为当前没有特权的网络名称空间(在容器的标准用法中)不是很有用，因为新的网络名称空间没有任何网络接口(除了lo之外)。链接网络名称空间(Veth网桥)的标准方式需要主机中的权限，而这在无根容器中不可用。解决这个问题的一些想法是在内核中实现非特权vethbridge，或者使用分路器实现某种类型的非特权用户空间veth桥实现。这个问题目前还没有定论，所以我们只使用主机的网络命名空间，到此为止。

已知一些系统调用(如setgroup(2)、seteuid(2)和chown(2))不能在无根容器中工作，除非使用SUID实用程序二进制文件(newuidmap(1)、newgidmap(1))配置了multipleUID/GID映射。众所周知，像APT和YUM这样的程序需要这样的系统调用才能工作。

虽然setgroup(2)和seteuid(2)对于执行它们的进程来说只是“临时的”，但是像chown(2)和minkd(2)这样的syscall实际上修改了持久存储，因此无根容器运行时可能希望以可互操作的方式持久保存这些数据。为此，我们定义了user.rootless tainers xattr属性。这对于使用Proot或REMAIN ROOT等工具模拟“真正的根”也很有用。runROOTLESS提供了实现user.rootless tainers xattr属性的Proot的派生版本。

添加对以非特权用户身份创建和修改标准化容器映像的工具的支持。

添加对工具的支持，该工具用于以非特权用户的身份提取和操作从标准化容器映像提取的根文件系统。

添加对作为非特权用户分发标准化容器映像的工具的支持。请注意，目前Open Container Initiative没有定义分发格式，因此“分发”指的是有效地执行rsync或类似的操作。一旦分配标准化，这一要求将得到扩展。

添加对storagedriver实现的支持，使其以非特权用户身份运行。这与“提取和操作”是分开的，因为朴素的实现(只是将所有东西转储到一个目录)原则上是有效的，但不如使用文件系统功能来减少提取图像的占用空间。

这些要求是由几个不同的工具实现的，每个工具都解决了难题的一部分。然后可以组合这些工具来创建图像存储或处理程序的“成熟”实现。

在这方面，分销是最简单的问题，由skopeo完成。原则上，Open Container InitiativeImage只能使用rsync进行复制，但是skopeo还有几个与不同图像格式之间的转换相关的功能，这使得它对各种其他任务非常有用。skopeo不需要任何核心功能的特权(事实上，通常用作非特权用户)。

提取、修改和创建由umoci实现。这些操作的主要问题是文件系统作为非特权用户的限制，因为有各种各样的操作是不允许的(出于安全原因)。因此，umoci的无根支持附带一些警告：

虽然umoci将作为特权用户重新创建容器映像的精确(或尽可能接近)根文件系统状态，但作为非特权用户，需要进行某些黑客攻击。例如，创建虚拟文件来代替无特权用户无法创建的设备节点，以及强制所有内容归当前无特权用户所有。因此，图像提取的结果可能与直觉相反，但在减少这些黑客攻击的怪诞方面做了大量工作。此外，umocirepack的实现方式不应该(在正常使用中)导致映像中包含umoci的黑客(如果您以特权用户的身份运行由非特权用户修改的映像，它应该可以正常工作)。但是，umoci支持前面提到的user.rootless tainers xattr属性的使用，这意味着接受user.rootless tainers属性的程序将能够正确互操作。

由于自主访问控制的工作方式，umoci在对提取的图像执行“只读”操作时，可能必须修改提取的图像的根文件系统。这意味着只读介质上的根文件系统(当umoci在它们上操作时)可能会遇到问题。

图像的构建是由orca-build实现的，它是一个围绕runc、umoci和skopeo的概念验证包装器。未来还有其他几个集装箱建造商项目可能会实现这一功能，但目前虎鲸的建造量已经足够快，而且相当少。它还具有与Dockerfileformat兼容的附加功能，用于指定构建步骤。

编排是目前最大的未知数。要使容器编排程序的大部分功能以非特权用户的身份运行，需要哪些任务的完整列表还不是很清楚。

实现容器网络接口插件以非特权用户身份运行的方式。这可能只涉及创建替代插件和替换特权版本。

这些任务没有太大的进展。然而，Cloud Foundry已经实现了实验性的无根容器支持。它们实现的缺点是，它仍然需要特权设置步骤，并且在容器生命周期中需要特权网络二进制文件(因此不会使其真正无根，但这是很好的第一步)。

以前在这个领域做过一些工作，但(据我们所知)没有如此雄心勃勃的工作。以下是具有某种无源容器支持的项目列表。

Bubblewrap(以前的xdg-app)以非特权用户的身份实现了部分容器运行时，但据我们所知，它没有实现足够的Open Container Initiative标准(即使使用BWRAP-OCI)也不足以成为一个完整的容器运行时。

LXC已经实现了相当一部分无根容器，但是它们的实现需要特权助手二进制文件来设置cgroup和网络接口。对于容器运行时来说，这是一个合理的折衷方案(runc的解决方案是忽略这些用例)，并且LXC确实有禁用这些二进制文件的旋钮，但这仍然意味着以本项目所需的方式使用LXC仍然是一件麻烦事。

binctr是JessieFrazelle编写的概念验证软件，也是runc中上游无根容器工作的灵感来源。它有一个有趣的附加特性，即创建一个包含容器运行时和容器根文件系统的静态二进制文件。

奇点是与无根容器的运行实现并行开发的。它是为HPC需求开发的运行时，因此基于这些需求有相当多奇怪的设计要求。然而，有一点值得注意的是，在其默认配置中，它有几个setuid二进制文件用于核心操作(例如挂载用作rootfs的环回设备)，这使得它对于无根容器要解决的用例来说是不切实际的。似乎Singulity确实支持用户名称空间，但是还不清楚完全无特权的设置是否常用，或者是否有足够的特性来与runc的无根容器竞争。

目前，一个人的聚会。但是如果你觉得这听起来很酷，请随时加入我的行列！我在Mastodon上，可以通过([电子邮件受保护])联系到。