podman：如何知道进程在podman中运行

Question

我正在运行一些应用程序，其中应用程序必须知道它在PODMAN内部运行，没有任何额外的env变量，但容器中的PODMAN配置必须提供细节，而没有任何用户交互。

现在，我正在使用cat/proc/self/cgroup | grep-I’机器。slice/libpod-*'容器内部开始使用podman检查进程是否在容器内部。

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

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默认使用主机cgroup命名空间，而Podman似乎也使用主机cgroup命名空间，因此这种流行的脏检查应该会成功，但它仍然是对无意的隔离破坏的利用，自从cgroup名称空间不存在时就存在了。

什么是替代方案？

当具体谈到Podman时，容器引擎似乎在容器规范创建过程中插入了一个特殊的环境变量，以指示容器化过程是使用特定的容器引擎启动的。因此，即使您在没有任何附加变量的情况下启动容器，您也可能会发现容器变量在其位置上：

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

虽然这种方法也不是防弹的（因为没有任何东西可以阻止容器创建者重写这个变量），但我觉得它比使用/proc/self/cgroup的技巧要好得多，因为这些东西是由容器引擎有意提供的，不太可能在无意中被重写，因为该变量不遵循一般命名约定，也不使用ALL_CAPS样式。