Chrome en Docker: ¿CAP_SYS_ADMIN vs privilegiado? [cerrado]

Estoy ejecutando chromedriver + chrome dentro de Docker en mi entorno de prueba.

Todo funcionaba bien hasta la última actualización de CoreOS.

Estas son las versiones que parecen funcionar:

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

Y esta es una versión más nueva que hace que Chrome reduzca el núcleo:

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

Al observar los cambios, parece que Docker se actualizó de 1.11.xa 1.12.x, lo que interrumpió la setns()llamada dentro del contenedor. setns()es utilizado por Chrome para crear espacios de nombres.

Estos son los resultados de ejemplo:

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

Desde el interior de un contenedor en esta caja:

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

Así es como la nueva versión lo rompió:

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)

Lo que he descubierto es que si comienzo del contenedor, ya sea con --cap-add=SYS_ADMINo --privileged- Chrome funciona como se esperaba.

¿Cuál es la diferencia entre esos dos interruptores? ¿Qué capacidades están habilitadas por --privileged?

Y, ¿puedo permitir el setns()interior del contenedor sin comprometer la seguridad?

AFAICS, la documentación sugiere otorgar las capacidades necesarias para un contenedor, en lugar de usar el --privilegedconmutador. La ejecución en modo privilegiado parece otorgarle al contenedor todas las capacidades (exactamente cuáles están enumeradas en la primera URL, siempre que los documentos estén actualizados).

En resumen, diría que --cap-add=SYS_ADMINotorga un subconjunto más pequeño de capacidades al contenedor, en comparación con el --privilegedconmutador. Event los ejemplos en la documentación de Docker (primer URL) parecen preferir simplemente agregar la capacidad SYS_ADMINo NET_ADMINcuando sea necesario.

Una diferencia es que - montajes privilegiados / dev y / sys como RW, mientras que SYS_ADMIN los monta como RO. Esto significa que un contenedor privilegiado tiene acceso completo a los dispositivos en el sistema. SYS_ADMIN no te da eso.