web-dev-qa-db-ja.com

Chrome Dockerの下：CAP_SYS_ADMIN vs特権？

私のテスト環境では、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
_

このボックスの1つのコンテナ内から：

_[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が期待どおりに機能することです。

これら2つのスイッチの違いは何ですか？ _--privileged_によって有効になる機能は何ですか？

また、セキュリティを犠牲にすることなく、コンテナ内でsetns()を許可できますか？

permissionsdockerchromenamespaces
11
Jakov Sosic

AFAICS、ドキュメント suggests--privilegedスイッチを使用するのではなく、コンテナに必要な機能を付与します。特権モードでの実行 付与するようですコンテナのすべての機能 （ドキュメントが最新の場合、最初のURLに正確にリストされているもの）.

要するに、--cap-add=SYS_ADMINスイッチと比較して、--privilegedは、機能のサブセットをコンテナに許可すると思います。 Dockerドキュメントの例（最初のURL）のイベントでは、必要に応じてSYS_ADMINまたはNET_ADMIN機能を追加することを好むようです。

7
ivuk

1つの違いは、-privilegedは/ devおよび/ sysをRWとしてマウントし、SYS_ADMINはそれらをROとしてマウントすることです。これは、特権コンテナがシステム上のデバイスに完全にアクセスできることを意味します。 SYS_ADMINはそれを提供しません。

1
mel1990