Docker 下的 Chrome：CAP_SYS_ADMIN 与特权？

Question

我在我的测试环境中在 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()容器内的调用。setns()Chrome 使用它来创建命名空间。

这是示例输出：

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或启动容器--privileged- Chrome 会按预期工作。

这两个开关有什么区别？启用了哪些功能--privileged？

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

Answer 1

AFAICS，文档建议授予容器所需的功能，而不是使用--privileged开关。在特权模式下运行似乎授予 容器所有功能（这些功能在第一个 URL 中列出，前提是文档是最新的）。

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