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

11

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?

permissions docker chrome namespaces Jakov Sosic
fuente
Gracias por esto. Resolví un problema, usando muchas de tus cosas: github.com/docker/for-linux/issues/496 Creo que debería arreglarse
Merc
Llegué 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.
Merc
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.
Merc

Respuestas:

7

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.

ivuk
fuente
Gracias exec_linux.goayudado. Intenté clonar el repositorio de Docker para analizarlo, pero como me llevó un par de horas, simplemente lo olvidé :)
Jakov Sosic
Solo para ejecutar Chrome, hay una solución mucho mejor lista aquí: github.com/docker/for-linux/issues/496#issuecomment-441149510 Creo que sería muy beneficioso actualizar la respuesta para que las personas hagan lo que explico en ese mismo comentario Avísame si estás de acuerdo.
Merc
1

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.

mel1990
fuente