Récemment, quelqu'un a ouvert un problème sur Podman.io :Dockerfile USER a-t-il un sens pour podman ? L'utilisateur tentait de configurer un conteneur pour exécuter un conteneur Postgresql en tant que non root. Il voulait créer un répertoire pour la base de données Postgresql dans son répertoire personnel et le monter en volume dans le conteneur :
$ 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
L'exécution de Podman sans root en tant que non-root a-t-elle un sens ?
Le problème qu'il rencontrait était que le répertoire qu'il avait créé dans le répertoire personnel, $PWD/html appartenait à son UID. Cet UID ressemble à root à l'intérieur du conteneur, et le processus Postgresql à l'intérieur du conteneur ne s'exécute pas en tant que root :il s'exécute en tant que postgres utilisateur (-u postgres ). Par conséquent, le processus Postgresql ne peut pas écrire dans le répertoire.
La solution simple à ce problème est de chown le html répertoire pour correspondre à l'UID avec lequel Postgresql s'exécute à l'intérieur du conteneur. Cependant, si l'utilisateur tente de chown le fichier :
chown postgres:postgres $PWD/html
chown: changing ownership of '/home/dwalsh/html': Operation not permitted
Ils obtiennent l'autorisation refusée. Ce résultat est dû au fait que l'utilisateur n'est pas root sur le système et qu'il n'est pas autorisé à chown des fichiers vers des UID aléatoires :
$ grep postgres /etc/passwd
postgres:x:26:26:PostgreSQL Server:/var/lib/pgsql:/bin/bash
Si l'utilisateur ajoute sudo pour chown le répertoire, ils obtiendront une erreur similaire. Maintenant, le répertoire appartient à l'UID 26, mais l'UID 26 n'est pas mappé dans le conteneur et n'est pas le même UID avec lequel Postgres s'exécute lorsqu'il se trouve dans le conteneur. Rappelez-vous de mes articles précédents sur l'espace de noms d'utilisateur que Podman lance un conteneur à l'intérieur de l'espace de noms d'utilisateur, qui est mappé avec la plage d'UID définie pour l'utilisateur dans /etc/subuid et /etc/subgid .
Sur mon système, je cours avec cet espace de noms d'utilisateur :
$ podman unshare cat /proc/self/uid_map
0 3267 1
1 100000 65536
Ce résultat montre que l'UID 0 est mappé sur mon UID, 3267, tandis que l'UID 1 est mappé sur 100000, l'UID 2 est mappé sur 100001, et ainsi de suite. Ce résultat signifie qu'à l'intérieur du conteneur, l'UID 26 s'exécute en tant qu'UID 100025.
Excellent, essayons ça :
$ chown 100025:100025 $PWD/html
chown: changing ownership of '/home/dwalsh/html': Operation not permitted
Eh bien, cela n'a pas fonctionné non plus. Le problème est que même si mon compte d'utilisateur peut exécuter un espace de noms d'utilisateur avec ces mappages, je ne suis actuellement pas dans un espace de noms d'utilisateur. J'ai besoin d'utiliser le podman unshare commande, qui vous dépose dans le même espace de noms d'utilisateur que celui utilisé par Podman sans racine, de sorte que les choses se ressemblent exactement pour unshare comme ils le font pour rootless :
$ podman unshare chown 100025:100025 $PWD/html
chown: changing ownership of '/home/dwalsh/html': Invalid argument
Error: exit status 1
Toujours incorrect. Le problème est maintenant que le chown se passe à l'intérieur de l'espace de noms de l'utilisateur, donc chown doit utiliser l'UID d'origine, pas l'UID mappé :
$ podman unshare chown 26:26 $PWD/html
En dehors de l'espace de noms d'utilisateur, ce résultat ressemble à :
$ ls -ld $PWD/html
drwxrwxr-x. 2 100025 100025 4096 Sep 13 07:14 /home/dwalsh/html
Désormais, lorsque l'utilisateur exécute le conteneur, il réussit. Le processus Postgresql à l'intérieur du conteneur s'exécute en tant qu'UID 26 à l'intérieur du conteneur (et 100025 à l'extérieur).
Mais revenons à la question initiale :"Est-ce que l'exécution de Podman sans racine en tant que non root a du sens ?" Si vous exécutez déjà le conteneur en tant que non root, pourquoi devriez-vous exécuter Postgresql en tant que non root différent dans le conteneur Podman ?
Par défaut, Podman sans racine s'exécute en tant que racine dans le conteneur. Cette politique signifie que les processus du conteneur ont la liste par défaut des capacités d'espace de noms qui permettent aux processus d'agir comme root à l'intérieur de l'espace de noms de l'utilisateur, y compris la modification de leur UID et le chowning des fichiers en différents UID qui sont mappés dans l'espace de noms de l'utilisateur. Si vous souhaitez exécuter le conteneur en tant qu'utilisateur Postgresql, vous souhaitez empêcher cet accès.
Cette configuration signifie également que les processus à l'intérieur du conteneur s'exécutent en tant qu'UID de l'utilisateur. Si le processus de conteneur s'échappait du conteneur, le processus aurait un accès complet aux fichiers de votre répertoire personnel en fonction de la séparation UID. SELinux bloquerait toujours l'accès, mais j'ai entendu dire que certaines personnes désactivent SELinux . Cela signifie que le processus échappé pourrait lire les secrets de votre répertoire personnel, comme ~/.ssh et ~/.gpg , ou d'autres informations auxquelles vous préféreriez que le conteneur n'ait pas accès.
Cependant, si vous exécutez les processus dans le conteneur en tant qu'UID non root différent, ces processus s'exécuteront sous cet UID. S'ils s'échappent du conteneur, ils n'auront accès qu'au contenu de votre répertoire personnel. Notez que pour travailler avec le contenu de ces répertoires, vous devez exécuter un podman unshare ou configurez la propriété du groupe des répertoires comme appartenant à votre UID (racine à l'intérieur du conteneur).
Avec Podman, vous souhaitez autoriser les utilisateurs à exécuter n'importe quelle image de conteneur sur n'importe quel registre de conteneurs en tant que non root si l'utilisateur le souhaite. Et je pense que l'exécution de conteneurs en tant que non root devrait toujours être votre priorité absolue pour des raisons de sécurité.
[Vous voulez essayer Red Hat Enterprise Linux ? Téléchargez-le maintenant gratuitement.]