Chrome en Docker: CAP_SYS_ADMIN vs privilegiado?

español
#1

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.0VERSION_ID=1185.5.0BUILD_ID=2016-12-07-0937

Y esta es una versión más nueva que hace que Chrome coredump:

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

Al observar los cambios, parece que Docker se actualizó desde 1.11.x a 1.12.x, que se rompió setns() llame al contenedor interior. setns() es utilizado por Chrome para crear espacios de nombres.

Estos son los resultados de ejemplo:

jsosic-coreos-test-20161207 ~ # docker --versionDocker 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 --versionDocker version 1.12.3, build 34a2ead[root@13ab34c36c82 /]# /opt/google/chrome/chromeFailed to move to new namespace: PID namespaces supported,  Network namespace supported,  but failed: errno = Operation not permittedAborted (core dumped)

Lo que he descubierto es que si inicio el contenedor con --cap-add=SYS_ADMIN o --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 setns() ¿contenedor interior sin comprometer la seguridad?

#2

AFAICS, la documentación sugerir concesión de las capacidades necesarias para un contenedor, en lugar de utilizar el --privileged interruptor. Ejecución en modo privilegiado parece conceder el contenedor todas las capacidades (exactamente cuáles son se enumeran en la primera URL, siempre que los documentos estén actualizados).

En resumen, diría que --cap-add=SYS_ADMIN otorga un subconjunto más pequeño de capacidades al contenedor, en comparación con el --privileged interruptor. Evento los ejemplos en la documentación de Docker (primera URL) parecen preferir simplemente agregar el SYS_ADMIN o NET_ADMIN capacidad donde sea necesario.

#3

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

#4

Gracias por esto. Hice un problema, usando muchas de tus cosas: Allow setns() in container, or add flag to allow it specifically · Issue #496 · docker/for-linux · GitHub Creo que debería arreglarse

#5

Llego casi 2 años tarde, pero hay una solución mucho mejor y más segura en el boleto anterior si aún está interesado.

#6

Si el póster original no actualiza la respuesta (no parece estar activo en SO en absoluto), avíseme si estaría disponible para aceptar una diferente. Perdí horas en esto, solo puedo imaginar cuántas horas salvaremos a otras personas.