☰

Docker 1.6.0 auf RHEL 6.5 mit SELinux, kann Container nicht ohne Root ausführen

tag-icon • tag-icon rhel6 docker selinux
Docker 1.6.0 auf RHEL 6.5 mit SELinux, kann Container nicht ohne Root ausführen

Ich versuche, einen Container auf RHEL 6.5 auszuführen, stoße jedoch ständig auf dieses Problem:

sudo docker run -u postgres -it registry/postgres /bin/bash
/bin/bash: error while loading shared libraries: libtinfo.so.5: cannot open shared object file: Permission denied

Wenn Sie den Container als Benutzer „root“ ausführen, startet er einwandfrei, aber das Problem tritt erneut auf, wenn Sie versuchen, zu einem anderen Benutzer zu wechseln:

$ sudo docker run -u root -it registry/database /bin/bash
[root@8a20410eaa5e /]# su postgres
su: /bin/bash: Permission denied

Dies ist ein spezieller von uns erstellter Container, der auf CentOS 6.5 basiert und Postgres ausführt. Das Dockerfile zum Erstellen enthält „USER postgres“ und funktioniert überall außer auf diesen Servern einwandfrei. Ich kann dasselbe Verhalten mit einem Busybox-Container reproduzieren:

$ sudo docker run -u nobody -it 10.188.13.136:8080/busybox
/ $ ls
/bin/sh: ls: Permission denied

Auf dem RHEL 6.5-Host ist SELinux aktiviert. Wir haben noch andere Hosts, auf denen SELinux und dieser Container einwandfrei funktionieren. Das Prüfprotokoll für diesen Host sieht sauber aus, ich sehe keine Fehlermeldungen, wenn ich versuche, den Container auszuführen.

Folgendes haben wir bisher versucht:

  • Aktualisieren Sie die SELinux-Richtlinien in RHEL ("sudo yum upgrade selinux-policy"), da es sich nicht um die neuesten Versionen handelt
  • SELinux in den permissiven Modus bringen (setenforce 0); nicht versucht, es vollständig auszuschalten und neu zu starten
  • Starten Sie den Docker-Daemon mit „--selinux-enabled=true“
  • Starten Sie den Container mit --privileged
  • Starten Sie den Container mit --security-opt=:label:disable
  • wir verwenden den neuesten RHEL 6.5-Kernel: 2.6.32-504.16.2.el6.x86_64

Führen Sie auch eine Strace-Sitzung für den Befehl „su“ innerhalb des Containers aus, aber darüber hinaus konnte ich nicht viel erkennen:

 17    setgid(10000)                     = 0
 17    setuid(10000)                     = 0
 17    munmap(0x7f07a3540000, 2101304)   = 0
 17    munmap(0x7f07a311c000, 2113776)   = 0
 17    munmap(0x7f07a2f03000, 2196352)   = 0
 17    munmap(0x7f07a2cea000, 2198192)   = 0
 17    munmap(0x7f07a2ae8000, 2101272)   = 0
 17    munmap(0x7f07a28e4000, 2109624)   = 0
 17    munmap(0x7f07a26e0000, 2109672)   = 0
 17    munmap(0x7f07a24d3000, 2148896)   = 0
 17    munmap(0x7f07a22d0000, 2105488)   = 0
 17    munmap(0x7f07a20cb000, 2113848)   = 0
 17    munmap(0x7f07a1ec5000, 2118168)   = 0
 17    munmap(0x7f07a3321000, 2221912)   = 0
 17    execve("/bin/bash", ["bash"], [/* 15 vars */]) = -1 EACCES (Permission denied)
 17    write(2, "su: ", 4)               = 4
 17    write(2, "/bin/bash", 9)          = 9

Der vollständige Strace-Dump ist hier, falls er benötigt wird:http://pastebin.com/42C2B8LP.

Wir sind nicht sicher, wonach wir als nächstes suchen sollen. Irgendwelche Ideen?

Antwort1

Ich konnte dieses Problem endlich lösen. Das heißt, ich habe anscheinend eine Lösung gefunden, bin mir aber immer noch nicht sicher, wo das Problem liegt:

1) Container aus Registry 2.0 ziehen + mit Docker 1.6 ausführen -> Fehler

2) Container aus Registry 0.9.x ziehen (entweder Dockers eigene oder der Artifactory-Server, den wir intern betreiben) + mit Docker 1.6 ausführen -> funktioniert

3) Container aus Registry 2.0 ziehen + mit Docker 1.5 oder älter ausführen -> fehlgeschlagen

4) Container aus Registry 0.9.x ziehen + mit Docker 1.5 oder neuer ausführen -> funktioniert

Ich glaube nicht wirklich, dass Registry 2.0 schuld ist, aber ich habe keine bessere Antwort. Die neue Registry ist viel schneller als die alte, aber ich schätze, wir werden vorerst bei der alten Registry bleiben.

verwandte Informationen