podman:如何知道进程在podman内部运行

Question

我正在运行一些应用程序，其中应用程序必须知道它在PODMAN内运行，而不需要任何额外的环境变量，但容器内的podman配置必须提供详细信息，而不需要任何用户交互。

到目前为止，我在容器内使用cat /proc/self/cgroup| grep -i 'machine.slice/libpod-*'开始使用podman来检查进程是否在pod内。

有没有更好的方法来处理同样的问题？

Answer 1

从纯理论的角度来看，使用带有/proc/self/cgroup的方法是一个坏主意，因为不能保证容器引擎不会在新的cgroup名称空间中产生容器，因此容器化进程将看到其当前的cgroup简单地作为/，如下面的示例所示(这里的unshare -C在启动容器时模拟容器引擎取消共享cgroup名称空间)：

$ podman run -it --privileged archlinux/base
[root@da0277b524db /]# unshare -C
-sh-5.0# cat /proc/self/cgroup
12:freezer:/
11:perf_event:/
10:pids:/
9:blkio:/
8:hugetlb:/
7:rdma:/
6:cpu,cpuacct:/
5:cpuset:/
4:net_cls,net_prio:/
3:memory:/
2:devices:/
1:name=systemd:/
0::/

从实践的角度来看，容器引擎似乎关心与这个技巧的兼容性，例如Moby uses the host cgroup namespace by default，而Podman似乎也使用了主机cgroup名称空间，所以这个流行的脏检查应该会成功，但它仍然是对无意隔离漏洞的利用，从cgroup名称空间还不存在的时候就存在了。

当具体谈到Podman时，容器引擎似乎在container spec creation期间插入了一个特殊的环境变量，以指示容器化进程是使用特定的容器引擎启动的。因此，即使您在启动容器时没有任何其他变量，您也可能会发现container变量位于它的位置：

$ podman run -it alpine
/ # env | grep container
container=podman

虽然这种方法也不是无懈可击的(因为没有什么可以阻止容器创建者覆盖这个变量)，但我觉得它比使用/proc/self/cgroup的技巧要好得多，因为这个东西是容器引擎故意提供的，而且它不太可能被无意中覆盖，因为这个变量不遵循一般的命名约定，也不使用ALL_CAPS样式。