Question

我目前正在追踪我们在17.10.0-ce主机上使用dockerd Alpine Linux 3.7时遇到的一个奇怪问题。对于此主机上的所有容器，似乎在Docker镜像的入口点/命令在容器本身内不可见时启动了进程树。相比之下，在Ubuntu主机上，相同的图像将进程树显示为PID 1。

这是一个例子。

使用显式已知入口点/命令运行容器：

% docker run -d --name testcontainer --rm busybox /bin/sh -c 'sleep 1000000'

验证dockerd正确看到进程：

% docker top testcontainer
PID                 USER                TIME                COMMAND
6729                root                0:00                /bin/sh -c sleep 1000000
6750                root                0:00                sleep 1000000

现在，在该容器中启动一个shell并检查进程列表：

% docker exec -t -i testcontainer /bin/sh
/ # ps -ef
PID   USER     TIME   COMMAND
    6 root       0:00 /bin/sh
   12 root       0:00 ps -ef

可以看出，我们的入口点命令（/ bin / sh -c'sleep 1000000'）在容器内部是不可见的。即使运行top也会产生相同的结果。

我在这里缺少什么吗？在具有相同docker引擎版本的Ubuntu主机上，结果如我所料。这可能与Alpine的硬化内核有关，导致容器PID空间如何分离？

对于要调查的领域有任何帮助。

-b

Answer 1

似乎这个问题与Alpine内核实现的 grsecurity 模块有关。在这种特定情况下，GRKERNSEC_CHROOT_FINDTASK内核设置用于限制在chroot环境之外可以执行的进程。这由kernel.grsecurity.chroot_findtask sysctl变量控制。

来自grsecurity文档：

kernel.grsecurity.chroot_findtask

如果你在这里说Y，chroot里面的进程将无法杀死，   使用fcntl，ptrace，capget，getpgid，setpgid，getsid或发送信号   查看chroot之外的任何进程。如果是sysctl选项   启用，一个名为＆＃34; chroot_findtask＆＃34;的sysctl选项;已创建。

我现在发现的唯一解决方法是禁用此标志以及chroot_deny_mknod和chroot_deny_chmod标志，以便获得与非grsecurity内核相同的行为。

kernel.grsecurity.chroot_deny_mknod=0
kernel.grsecurity.chroot_deny_chmod=0
kernel.grsecurity.chroot_findtask=0

当然这不太理想，因为它绕过并禁用了系统的安全功能，但可能是开发环境的有效解决方法。

Alpine Linux 3.7上的Docker容器：在容器的pid命名空间

1 个答案: