☰

Docker 下的 Chrome：CAP_SYS_ADMIN 与特权？

tag-icon • tag-icon permissions docker chrome namespaces
Docker 下的 Chrome：CAP_SYS_ADMIN 与特权？

我在我的测试环境中在 Docker 中运行 chromedriver + chrome。

在最新的 CoreOS 升级之前，一切都运行良好。

这些版本似乎有效：

VERSION=1185.5.0
VERSION_ID=1185.5.0
BUILD_ID=2016-12-07-0937

这是一个导致 chrome 核心转储的较新版本：

VERSION=1235.4.0
VERSION_ID=1235.4.0
BUILD_ID=2017-01-04-0450

查看变化，似乎 docker 从 1.11.x 升级到了 1.12.x，这中断了setns()容器内部的调用。Chromesetns()使用它创建命名空间。

以下是示例输出：

jsosic-coreos-test-20161207 ~ # docker --version
Docker version 1.11.2, build bac3bae

从此盒子中的一个容器内部：

[root@2939f21ecfaa /]# /opt/google/chrome/google-chrome
[57:57:0107/015130:ERROR:browser_main_loop.cc(261)] Gtk: cannot open display:

新版本是这样打破这一现状的：

jsosic-coreos-test-2017-01-04 ~ # docker --version
Docker version 1.12.3, build 34a2ead

[root@13ab34c36c82 /]# /opt/google/chrome/chrome
Failed to move to new namespace: PID namespaces supported,
  Network namespace supported,
  but failed: errno = Operation not permitted
Aborted (core dumped)

我发现，如果我使用 或 启动容器--cap-add=SYS_ADMIN，--privilegedChrome 就会按预期工作。

这两个交换机有什么区别？ 启用了哪些功能--privileged？

并且，我可以setns()在不影响安全的情况下允许进入容器吗？

答案1

AFAICS，文档建议授予容器所需的功能，而不是使用开关--privileged。以特权模式运行似乎同意 容器所有功能（如果文档是最新的，那么第一个 URL 中就会列出具体的内容）。

简而言之，我认为--cap-add=SYS_ADMIN与交换机相比，它授予容器的功能子集更小--privileged。Docker 文档（第一个 URL）中的示例似乎更倾向于在需要时添加SYS_ADMIN或功能。NET_ADMIN

答案2

一个区别是 --privileged 将 /dev 和 /sys 挂载为 RW，而 SYS_ADMIN 将它们挂载为 RO。这意味着特权容器对系统上的设备具有完全访问权限。SYS_ADMIN 不会给您这个权限。

相关内容