Chrome sotto Docker: CAP_SYS_ADMIN vs privilegiato? [chiuso]

11

Sto eseguendo chromedriver + chrome all'interno di Docker nel mio ambiente di test.

Tutto funzionava bene fino all'ultimo aggiornamento CoreOS.

Queste sono le versioni che sembrano funzionare:

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

E questa è una versione più recente che causa il coredump di Chrome:

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

Osservando le modifiche, sembra che la finestra mobile sia stata aggiornata dalla 1.11.x alla 1.12.x, che ha interrotto la setns()chiamata all'interno del contenitore. setns()viene utilizzato da Chrome per la creazione di uno spazio dei nomi.

Questi sono gli output di esempio:

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

Dall'interno di un contenitore su questa scatola:

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

Ecco come la nuova versione l'ha rotto:

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)

Quello che ho scoperto è che se avvio il contenitore con uno --cap-add=SYS_ADMINo --privileged- Chrome funziona come previsto.

Qual è la differenza tra questi due interruttori? Quali funzionalità sono abilitate da --privileged?

E, posso consentire il setns()contenitore interno senza compromettere la sicurezza?

— Jakov Sosic
fonte

Grazie per questo. Ho fatto un problema, usando molte delle tue cose: github.com/docker/for-linux/issues/496 Penso che dovrebbe essere risolto

— Merc

Sono quasi 2 anni in ritardo, ma c'è una soluzione molto migliore e più sicura nel biglietto sopra se sei ancora interessato.

— Merc

Se il poster originale non aggiorna la risposta (non sembra affatto attivo su SO), fammi sapere se saresti disponibile ad accettarne una diversa. Ho perso ore su questo, posso solo immaginare quante ore salveremo altre persone.

— Merc

7

AFAICS, la documentazione suggerisce di concedere le capacità necessarie per un contenitore, anziché utilizzare lo --privilegedswitch. L'esecuzione in modalità privilegiata sembra garantire al contenitore tutte le funzionalità (esattamente quali sono elencate nel primo URL, a condizione che i documenti siano aggiornati).

In breve, direi che --cap-add=SYS_ADMINgarantisce un sottoinsieme più piccolo di funzionalità al container, rispetto allo --privilegedswitch. Evento, gli esempi nella documentazione Docker (primo URL) sembrano preferire semplicemente l'aggiunta della funzionalità SYS_ADMINo NET_ADMINdove necessario.

— ivuk
fonte

Grazie, exec_linux.goaiutato Ho provato a clonare il repository

— docker per superarlo

Proprio per eseguire Chrome, c'è una soluzione molto migliore elencati qui: github.com/docker/for-linux/issues/496#issuecomment-441149510 Penso che sarebbe molto utile per aggiornare la risposta in modo che la gente fa quello che spiego nel proprio quel commento. Per favore fatemi sapere se siete d'accordo.

— Merc

1

Una differenza è che - privilegiato monta / dev e / sys come RW, dove SYS_ADMIN li monta come RO. Ciò significa che un contenitore privilegiato ha pieno accesso ai dispositivi sul sistema. SYS_ADMIN non ti dà questo.

— mel1990
fonte