Manchmal wundern sich Benutzer über die Einschränkungen des Rootless-Modus für Buildah- und Podman-Container-Engines. Mit dem Rootless-Modus erweitern wir die Grenzen dessen, was ein nicht privilegierter Benutzer tun kann. Einer meiner Jobs ist es, mit den Kernel-Teams und den Dateisystem-Teams zusammenzuarbeiten, um rootless besser zu machen. In diesem Artikel erkläre ich, warum das Mounten von Images im Rootless-Modus schwieriger ist.
[Das könnte Ihnen auch gefallen:Balance zwischen Linux-Sicherheit und Benutzerfreundlichkeit]
Rootless-Montage
Ein normaler Benutzer kann kein Dateisystem einhängen, es sei denn, er befindet sich in einem Benutzernamensraum zusammen mit einem eigenen Mount-Namespace . Ein Mount-Namespace erlaubt Prozessen darin, Dateisysteme zu mounten, die vom Host-Mount-Namespace nicht gesehen werden. Diese Kernel-Einschränkung schützt das Hostbetriebssystem vor potenziellen Angriffen, bei denen ein Nutzer Inhalte über /tmp bereitstellen könnte oder sogar in ihrem Home-Verzeichnis und täuschen dann andere Prozesse auf dem System oder Administratoren dazu, die Einhängepunkte zu verwenden.
Sobald der Prozess des Benutzers dem Benutzernamensraum und dem neuen Mount-Namensraum beitritt, erlaubt der Kernel nur das Einhängen bestimmter Dateisysteme. Während ich dies schreibe, erlaubt der Kernel die Dateisysteme sysfs, procfs, tmpfs, bind mount und fuse. Wir haben kürzlich einen Patch in den Upstream-Kernel bekommen, um Overlay-Dateisysteme zu unterstützen, was eine große Verbesserung sein wird, aber derzeit haben die meisten Distributionen diese Unterstützung nicht. Ich würde gerne NFS-Unterstützung bekommen, aber das birgt Sicherheitsrisiken. Hoffentlich wird der Kernel diese Probleme beheben und schließlich unterstützt werden.
Rootlose Container-Engines wie Podman und Buildah erstellen automatisch ihren eigenen Benutzernamensraum und Mount-Namensraum, wenn sie ausgeführt werden. Wenn der Container-Engine-Prozess beendet wird, verschwinden der Benutzer- und Mount-Namespace, und der Benutzerprozess kehrt zum Host-Mount-Namespace zurück. An diesem Punkt sind die während der Ausführung der Tools erstellten Mounts für andere Prozesse auf dem Host nicht mehr sichtbar oder verwendbar.
Warum ist das wichtig?
Eine der coolen Funktionen von Buildah besteht darin, Benutzern den Zugriff auf die Low-Level-Semantik des Containerbaus zu ermöglichen. Die meisten Container-Image-Builder haben nur eine Methode zum Erstellen von Containern – im Grunde die Verwendung von Containerfiles oder Dockerfiles. Buildah bud unterstützt das Bauen mit diesen Dateien. Buildah ermöglicht es Benutzern auch, Container mit Low-Level-Primitiven zu erstellen. Nutzer können damit ein Verzeichnis erstellen, das Verzeichnis mit Inhalten füllen, ein Image erstellen und es per Push in eine Registry übertragen.
# ctr=$(buildah from scratch)
# mnt=$buildah mount $ctr)
# dnf -y --install-root $mnt httpd
# buildah config --entrypoint .... $ctr
# buildah commit $ctr IMAGE
# buildah push IMAGE REGISTRY Das alles funktioniert hervorragend, wenn es als Root ausgeführt wird, aber wenn Benutzer versuchen, dies im Rootless-Modus auszuführen, explodieren ihre Skripte.
$ mnt=$(buildah mount $ctr)
cannot mount using driver overlay in rootless mode. You need to run it in a `buildah unshare` session
Das Problem ist mnt=$(buildah mount $ctr) weigert sich, das Image mit dem Overlay-Treiber zu mounten, wenn Sie buildah unshare nicht ausgeführt haben .
Ein genauerer Blick
Wenn Sie buildah ausführen Befehle wie bud und run , im Rootless-Modus, die buildah Der Befehl gibt den Benutzer- und Mount-Namespace ein. Es mountet das Container-Dateisystem einwandfrei und führt die Befehle aus. Wenn der Befehl abgeschlossen ist, buildah beendet, wodurch die Namespaces zerstört werden. Wenn Sie dies mit dem mount tun Befehl wurde das gemountete Dateisystem nie im Host-Mount-Namespace gesehen. Buildah prüft nun auf diese Situation und meldet dem Benutzer, dass er ein buildah unshare ausgeben muss zuerst.
buildah unshare
Buildah und Podman haben einen speziellen Befehl, unshare . Dieser Befehl erstellt und betritt den Benutzernamensraum, ohne einen Container zu erstellen oder mit ihm zu interagieren. Es ist tatsächlich ziemlich interessant, diesen Modus zu erkunden, um vollständig zu verstehen, was der Benutzernamensraum tut. Ausführen von buildah unshare command führt einen Shell-Befehl in den Namespaces aus, der als root ausgeführt wird im Benutzernamensraum. Jetzt können Sie jeden Befehl ausführen, einschließlich buildah oben beschriebenen Befehle. Da sich diese Befehle bereits in den Namespaces befinden, muss der buildah mount Der Befehl funktioniert genauso wie im Rootful-Modus. Alles geschieht innerhalb der Namensräume und der Benutzer bekommt, was er erwartet.
Jetzt könnte der Benutzer die oben aufgeführten Befehle ausführen und ein Shell-Skript erstellen. Dieses Shellscript wird dann direkt mit dem buildah unshare ausgeführt Befehl.
$ cat > buildahimage.sh < _EOF
ctr=$(buildah from scratch)
mnt=$buildah mount $ctr)
dnf -y --install-root $mnt httpd
buildah config --entrypoint .... $ctr
buildah commit $ctr IMAGE
buildah push IMAGE REGISTRY
< _EOF
chmod +x /buildahimage.sh
buildah unshare ./buildimage.sh [ Erste Schritte mit Containern? Schauen Sie sich diesen kostenlosen Kurs an. Containerisierte Anwendungen bereitstellen:Eine technische Übersicht. ]
Abschluss
Leider können wir nicht alles innerhalb des Kernels reparieren, um Benutzern die wurzellose Erfahrung zu bieten, die sie erwarten, hauptsächlich wegen Sicherheitsbedenken. Aber wir können ganz nah ran. Und natürlich können Sie jederzeit im Root-Modus arbeiten, wenn Sie zusätzliche Funktionen benötigen.