权限 – Docker下的Chrome：CAP_SYS_ADMIN vs特权？

我在我的测试环境中运行了Docker中的chromedriver chrome.

一切正常,直到最新的CoreOS升级.

这些版本似乎有效：

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

这是一个导致chrome coredump的新版本：

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

看看变化,似乎docker从1.11.x升级到1.12.x,这破坏了容器内的setns()调用. Chrome使用setns()来创建命名空间.

这是示例输出：

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()而不会影响安全性吗？

AFAICS,文档 suggests授予容器所需的功能,而不是使用–privileged开关.在特权模式 seems to grant the container all capabilities中运行(如果文档是最新的,则确切地列在第一个URL中的那些模式).

简而言之,与–privileged开关相比,我会说–cap-add = SYS_ADMIN为容器授予一小部分功能.事件Docker文档(第一个URL)中的示例似乎更喜欢在需要时添加SYS_ADMIN或NET_ADMIN功能.