Chrome unter Docker: CAP_SYS_ADMIN vs privilegiert? [geschlossen]

11

Geschlossen. Diese Frage ist nicht zum Thema . Derzeit werden keine Antworten akzeptiert.

Möchten Sie diese Frage verbessern? Aktualisieren Sie die Frage so dass es beim Thema für Server Fehler.

Geschlossen vor 8 Monaten .

Ich verwende chromedriver + chrome in Docker in meiner Testumgebung.

Bis zum letzten CoreOS-Upgrade funktionierte alles einwandfrei.

Dies sind die Versionen, die zu funktionieren scheinen:

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

Und dies ist eine neuere Version, die dazu führt, dass Chrom entleert wird:

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

Angesichts der Änderungen scheint Docker von 1.11.x auf 1.12.x aktualisiert worden zu sein, wodurch der setns()Aufruf im Container unterbrochen wurde . setns()wird von Chrome zum Erstellen von Namespaces verwendet.

Dies sind die Beispielausgaben:

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

Aus einem Behälter auf dieser Box:

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

So hat es die neue Version gebrochen:

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)

Was ich herausgefunden habe ist, dass wenn ich den Container mit entweder --cap-add=SYS_ADMINoder --privileged- starte, Chrome wie erwartet funktioniert.

Was ist der Unterschied zwischen diesen beiden Schaltern? Welche Funktionen werden von aktiviert --privileged?

Und kann ich Innencontainer zulassen setns(), ohne die Sicherheit zu beeinträchtigen?

— Jakov Sosic
quelle

Danke dafür. Ich habe ein Problem mit vielen Ihrer Sachen gemacht: github.com/docker/for-linux/issues/496 Ich denke, es sollte behoben werden

— Merc

Ich bin fast 2 Jahre zu spät, aber es gibt eine viel bessere und sicherere Lösung im obigen Ticket, wenn Sie noch interessiert sind.

— Merc

Wenn das Originalposter die Antwort nicht aktualisiert (er scheint auf SO überhaupt nicht aktiv zu sein), lassen Sie mich wissen, ob Sie verfügbar sind, um eine andere zu akzeptieren. Ich habe Stunden damit verschwendet, ich kann mir nur vorstellen, wie viele Stunden wir andere Menschen retten werden.

— Merc

7

AFAICS, die Dokumentation schlägt vor , die Möglichkeiten Gewährung für einen Behälter benötigt, anstatt der Verwendung von --privilegedSchalter. Das Ausführen im privilegierten Modus scheint dem Container alle Funktionen zu gewähren (genau die, die in der ersten URL aufgeführt sind, sofern die Dokumente auf dem neuesten Stand sind).

Kurz gesagt, ich würde sagen, dass --cap-add=SYS_ADMINdem Container im Vergleich zum --privilegedSwitch eine kleinere Teilmenge von Funktionen gewährt wird . Eventuell scheinen die Beispiele in der Docker-Dokumentation (erste URL) es vorzuziehen , bei Bedarf nur die Funktion SYS_ADMINoder hinzuzufügen NET_ADMIN.

— ivuk
quelle

Danke, exec_linux.gogeholfen. Ich habe versucht, Docker Repo zu klonen, um es zu

— durchsuchen,

Um Chrome auszuführen, gibt es hier eine viel bessere Lösung: github.com/docker/for-linux/issues/496#issuecomment-441149510 Ich denke, es wäre sehr vorteilhaft, die Antwort zu aktualisieren, damit die Leute das tun, was ich in erkläre genau dieser Kommentar. Bitte lassen Sie mich wissen, wenn Sie einverstanden sind.

— Merc

1

Ein Unterschied besteht darin, dass --privilegierte / dev und / sys als RW bereitgestellt werden, während SYS_ADMIN sie als RO bereitstellt. Dies bedeutet, dass ein privilegierter Container vollen Zugriff auf Geräte im System hat. SYS_ADMIN gibt Ihnen das nicht.

— mel1990
quelle