☰

环境详情

tag-icon • tag-icon centos docker selinux
环境详情

环境详情

$docker --version

Docker 版本 19.03.4，内部版本 9013bf583a

$hostnamectl

   Static hostname: ohpc.novalocal
         Icon name: computer-vm
           Chassis: vm
        Machine ID: 93f219319dd5bdb42d9f1c8f2e23d329
           Boot ID: c957802410104779a1e1e4c6ff52800c
    Virtualization: kvm
  Operating System: CentOS Linux 7 (Core)
       CPE OS Name: cpe:/o:centos:centos:7
            Kernel: Linux 3.10.0-957.12.2.el7.x86_64
      Architecture: x86-64

$cat /etc/centos-release

CentOS Linux 版本 7.7.1908（核心）

问题

我在 Ubuntu 上成功运行了一些程序，似乎已经解决了差异，但我不确定如何解决，因为它几乎看起来像是一个转移注意力的话题。以下是我遇到问题的主机 (Centos) 的信息：

$ ls -Z /usr/bin/docker
-rwxr-xr-x. root root system_u:object_r:container_runtime_exec_t:s0 /usr/bin/docker

我已经将 docker 可执行文件（和 .sock）安装到我的 Ubuntu 机器上的 Jenkins 容器中，以便它可以执行 docker 命令。摘自我的 compose yml，请注意，我尝试了等效的 docker run 命令、docker-compose up 和 docker stack deploy，但均未成功。

    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - /usr/bin/docker:/usr/bin/docker
    privileged: true

即使它在容器中可见且可执行，但我无法执行它：

$ docker exec -it tmp_jenkins_1 bash
bash-4.4$ which docker
/usr/bin/docker
bash-4.4$ ls -al /usr/bin/docker
-rwxr-xr-x 1 root root 88960560 Oct 18 15:53 /usr/bin/docker
bash-4.4$ docker --version
bash: /usr/bin/docker: No such file or directory
bash-4.4$ /usr/bin/docker --version
bash: /usr/bin/docker: No such file or directory

我所看到的工作环境 (Ubuntu) 环境和失败环境 (CentOS) 之间的唯一区别是.文件权限 (selinux acl 策略) 末尾的。但是，我尝试过setenforce Permissive，这并没有改变任何观察结果，所以我怀疑这不是 SELinux。

工作机器上不存在docker。centos机器上的 daemon.json 中daemon.json有一个特殊的 dns。mtu:1200

登录后/var/log/messages没有显示任何有用的信息。

编辑 - 11 - 6 - 2019

我遇到过并尝试过的一些其他事情：

我尝试过彻底禁用 SELinux这仍然导致上述未找到文件错误（之后再次启用）。

尝试了一下 daemon.json，selinux-enabled": false并selinux-enabled": true添加了以下内容这篇文章介绍了如何让 SELinux 与 /etc 和 /usr 主机目录很好地协调

启用后，我在运行时收到来自 SELinux 的错误，指出/usr/bin/docker无法重写在卷语句末尾添加的各种枚举z和属性的标签（请注意，尝试了语法和语法更改 - 我希望我们不想锁定 docker.sock 或 docker 可执行文件只能在目标容器内访问。Zdocker rundocker-compose.ymlz

    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:z
      - /usr/bin/docker:/usr/bin/docker:z
    privileged: true

我也尝试过docker run --security-opt label:disable ...同时使用 with 和privilegedto的替代方法绕过 SELinux 政策。我注意到 RedHat 文档中有一些关于该主题的信息，但有趣的是没有docker_connect_any旗帜。

重要的布尔值和其他限制 - docker 下的“特权”并非真正的特权。即使是特权 docker 进程也无法访问任意套接字文件。SElinux 布尔值 docker_connect_any 使特权 docker 进程能够访问任意套接字文件。即使以特权方式运行，docker 也会受到有效布尔值的限制。

最后的想法是，我遇到了一些关于一切主题的有用的文章和文档，但仍然缺乏解决方案。

docker inspect -f '{{ .ProcessLabel }}' tmp_jenkins_1在所有尝试中都没有给出任何标签，我期望selinux-enabled在 daemon.json 中启用后请参阅一些 SELinux 语法ProcessLabel，但没有。

答案1

事实证明 SELinux 实际上是一个转移注意力的花招……我改变了形象从 到jenkinsci/blueocean一切jenkinsci/jenkins​​按预期运行（启用 SELinux）

现在来谈谈理由：

jenkinsci/blueocean（至少在撰写本文时）显然在图像中安装了docker。

那是，您无法将可执行文件挂载在可执行文件上并期望一切正常，因为如果内容已经存在，卷不应覆盖。我猜测这是主机操作系统二进制文件+Docker 映像的组合，这就是为什么它在一个主机操作系统上运行而在另一个主机操作系统上运行不起来的原因。

无论哪种方式，都是因为可执行文件已经存在于图像中，因此也存在于容器中。

本来想删除，但我把我的答案概括了一下，因为我可以看到这个奇怪情况的原因是其他人可能会在更广泛的意义上经历的事情。

相关内容