Kürzlich hat jemand ein Problem auf Podman.io geöffnet:Macht Dockerfile USER Sinn für Podman? Der Benutzer hat versucht, einen Container einzurichten, um einen Postgresql-Container als Nicht-Root auszuführen. Er wollte ein Verzeichnis für die Postgresql-Datenbank in seinem Home-Verzeichnis erstellen und es in den Container einbinden:
$ podman run -it **-v "$PWD"/html:/output:Z** schemaspy/schemaspy:snapshot -u postgres -t pgsql11 -host 192.168.4.1 -port 5432 -db anitya
...
INFO - Starting Main v6.1.0-SNAPSHOT on 9090a61652af with PID 1 (/schemaspy-6.1.0-SNAPSHOT.jar started by java in /)
INFO - The following profiles are active: default
INFO - Started Main in 2.594 seconds (JVM running for 3.598)
INFO - Starting schema analysis
**ERROR - IOException**
**Unable to create directory /output/tables**
INFO - StackTraces have been omitted, use `-debug` when executing SchemaSpy to see them
Macht es Sinn, rootless Podman als Nicht-Root auszuführen?
Das Problem, das er hatte, war, dass das von ihm erstellte Verzeichnis im Home-Verzeichnis $PWD/html gehörte seiner UID. Diese UID sieht aus wie root innerhalb des Containers, und der Postgresql-Prozess innerhalb des Containers wird nicht als root ausgeführt:Er wird als postgres ausgeführt Benutzer (-u postgres ). Daher kann der Postgresql-Prozess nicht in das Verzeichnis schreiben.
Die einfache Lösung für dieses Problem besteht darin, html zu chown Verzeichnis so, dass es mit der UID übereinstimmt, mit der Postgresql innerhalb des Containers ausgeführt wird. Wenn der Benutzer jedoch versucht, die Datei zu ändern:
chown postgres:postgres $PWD/html
chown: changing ownership of '/home/dwalsh/html': Operation not permitted
Ihnen wird die Erlaubnis verweigert. Dieses Ergebnis liegt daran, dass der Benutzer nicht root auf dem System ist und keine Dateien auf zufällige UIDs chownen darf:
$ grep postgres /etc/passwd
postgres:x:26:26:PostgreSQL Server:/var/lib/pgsql:/bin/bash
Wenn der Benutzer sudo hinzufügt um das Verzeichnis zu ändern, erhalten sie einen ähnlichen Fehler. Jetzt gehört das Verzeichnis der UID 26, aber die UID 26 ist nicht dem Container zugeordnet und ist nicht dieselbe UID, mit der Postgres im Container ausgeführt wird. Erinnern Sie sich aus meinen vorherigen Artikeln zum Benutzernamensraum daran, dass Podman einen Container innerhalb des Benutzernamensraums startet, der dem UID-Bereich zugeordnet ist, der für den Benutzer in /etc/subuid definiert ist und /etc/subgid .
Auf meinem System laufe ich mit diesem Benutzernamensraum:
$ podman unshare cat /proc/self/uid_map
0 3267 1
1 100000 65536
Dieses Ergebnis zeigt, dass UID 0 meiner UID 3267 zugeordnet ist, während UID 1 100000 zugeordnet ist, UID 2 100001 zugeordnet ist und so weiter. Dieses Ergebnis bedeutet, dass UID 26 innerhalb des Containers als UID 100025 läuft.
Ausgezeichnet, versuchen wir das:
$ chown 100025:100025 $PWD/html
chown: changing ownership of '/home/dwalsh/html': Operation not permitted
Nun, das hat auch nicht funktioniert. Das Problem ist, dass ich mich derzeit nicht in einem Benutzernamensraum befinde, obwohl mein Benutzerkonto einen Benutzernamensraum mit diesen Zuordnungen ausführen kann. Ich muss den podman unshare verwenden Befehl, der Sie in denselben Benutzernamensraum versetzt, den rootless Podman verwendet, sodass die Dinge für unshare genau gleich aussehen wie sie es für rootless tun:
$ podman unshare chown 100025:100025 $PWD/html
chown: changing ownership of '/home/dwalsh/html': Invalid argument
Error: exit status 1
Immer noch falsch. Das Problem ist nun, dass chown geschieht innerhalb des Benutzernamensraums, also chown muss die ursprüngliche UID verwenden, nicht die zugeordnete UID:
$ podman unshare chown 26:26 $PWD/html
Außerhalb des Benutzernamensraums sieht dieses Ergebnis folgendermaßen aus:
$ ls -ld $PWD/html
drwxrwxr-x. 2 100025 100025 4096 Sep 13 07:14 /home/dwalsh/html
Wenn der Benutzer den Container jetzt ausführt, ist er erfolgreich. Der Postgresql-Prozess innerhalb des Containers läuft als UID 26 innerhalb des Containers (und 100025 außerhalb).
Aber kehren wir zur ursprünglichen Frage zurück:„Macht es Sinn, rootless Podman als Nicht-Root auszuführen?“ Wenn Sie den Container bereits als Nicht-Root ausführen, warum sollten Sie dann Postgresql als einen anderen Nicht-Root im Podman-Container ausführen?
Standardmäßig läuft Podman ohne Root als Root innerhalb des Containers. Diese Richtlinie bedeutet, dass die Prozesse im Container die Standardliste von Namespace-Fähigkeiten haben die es den Prozessen ermöglichen, sich innerhalb des Benutzernamensraums wie root zu verhalten, einschließlich des Änderns ihrer UID und des Änderns von Dateien in andere UIDs, die dem Benutzernamensraum zugeordnet sind. Wenn Sie den Container als Postgresql-Benutzer ausführen möchten, möchten Sie diesen Zugriff verhindern.
Dieses Setup bedeutet auch, dass die Prozesse innerhalb des Containers als UID des Benutzers ausgeführt werden. Wenn der Containerprozess den Container maskiert hat, hätte der Prozess basierend auf der UID-Trennung vollen Zugriff auf Dateien in Ihrem Home-Verzeichnis. SELinux würde immer noch den Zugriff blockieren, aber ich habe gehört, dass einige Leute SELinux deaktivieren . Dies bedeutet, dass der Escape-Prozess die Geheimnisse in Ihrem Home-Verzeichnis lesen könnte, wie ~/.ssh und ~/.gpg , oder andere Informationen, auf die der Container keinen Zugriff haben soll.
Wenn Sie die Prozesse innerhalb des Containers jedoch unter einer anderen Nicht-Root-UID ausführen, werden diese Prozesse unter dieser UID ausgeführt. Wenn sie aus dem Container entkommen, haben sie nur weltweiten Zugriff auf Inhalte in Ihrem Home-Verzeichnis. Beachten Sie, dass Sie zum Arbeiten mit den Inhalten in diesen Verzeichnissen einen podman unshare ausführen müssen Befehl oder richten Sie den Gruppenbesitz der Verzeichnisse so ein, dass er Ihrer UID gehört (Root innerhalb des Containers).
Mit Podman möchten Sie es Benutzern ermöglichen, jedes Container-Image in jeder Container-Registrierung als Nicht-Root auszuführen, wenn der Benutzer dies wünscht. Und ich glaube, dass das Ausführen von Containern als Nicht-Root aus Sicherheitsgründen immer Ihre oberste Priorität sein sollte.
[Möchten Sie Red Hat Enterprise Linux ausprobieren? Jetzt kostenlos herunterladen.]