L'un des principaux problèmes rencontrés par les utilisateurs de Podman est l'accès aux fichiers et aux périphériques qu'ils peuvent utiliser à partir de l'hôte mais qu'ils ne peuvent pas utiliser dans un conteneur, même s'ils montent en volume les objets dans le conteneur.
Dans ce cas, nous allons examiner l'accès de groupe supplémentaire. Souvent, les systèmes sont configurés avec des fichiers et des périphériques qui ne sont accessibles qu'à des groupes d'utilisateurs spécifiques. Par exemple, je suis dans la roue groupe sur mon système, ce qui permet à mon utilisateur d'accéder à certains contrôles administratifs. Les administrateurs peuvent configurer un répertoire à partager par plusieurs utilisateurs sur le système en créant le eng groupe, ajout d'utilisateurs au eng groupe, puis en autorisant le eng groupe pour avoir le répertoire rwx autorisations. Maintenant, tous les utilisateurs en eng peut lire et écrire dans le répertoire.
Récemment, nous avons reçu un problème où un utilisateur avait du mal à donner accès à un périphérique GPU sur son système.
Il ajoutait l'appareil à l'aide d'une commande telle que :
$ podman run --device /dev/video0 … Remarque :Dans les conteneurs sans racine, les utilisateurs sans racine ne peuvent pas créer de nouveaux appareils lors de l'ajout d'un appareil à un conteneur. Donc, Podman se contente de monter l'appareil du conteneur dans l'hôte. En mode rootfull, un nouveau périphérique est créé auquel les processus à l'intérieur du conteneur ont accès.
Le volume Podman se monte dans /dev/video0 , mais chaque fois que l'utilisateur tente d'utiliser l'appareil dans le conteneur, il échoue avec Autorisation refusée . Cependant, lorsqu'il a vérifié l'appareil sur l'hôte et les groupes dont il était membre, tout semblait correct. Par exemple :
$ ls -l /dev/video0
crw-rw----+ 1 root video 81, 0 May 3 14:06 /dev/video0
$ groups
dwalsh video Il peut pleinement utiliser l'appareil en dehors des conteneurs. Réaliser que le processus de conteneur n'est pas dans la vidéo groupe, il a alors pensé à ajouter la vidéo group au conteneur pour y accéder. Il a essayé cette commande :
$ podman run --group-add video --device /dev/video0 … Mais cela a quand même échoué avec Autorisation refusée .
Que s'est-il passé ?
Lorsque vous utilisez --group-add video , il ajoute la vidéo groupe défini à l'intérieur de l'image du conteneur au processus principal du conteneur, comme ceci :
$ grep video /etc/group
video: 39:
$ podman run --group-add video fedora id
uid=0(root) gid=0(root) groups=0(root),39(video)
À l'intérieur du conteneur, le processus a le groupe 39 , mais ce n'est pas identique au groupe 39 sur l'hôte. Lors de l'exécution de conteneurs sans racine, vous utilisez l'espace de noms d'utilisateur afin que le groupe soit décalé par l'espace de noms d'utilisateur que vous avez rejoint. Voici l'espace de noms :
$ podman unshare cat /proc/self/gid_map
0 3267 1
1 100000 65536
Cela signifie que la vidéo groupe à l'intérieur du conteneur sera GID 100038 sur l'hôte. Jetez un oeil à cet exemple :
$ ctr=$(podman run -d --group-add video fedora sleep 100)
$ pid=$(podman top -l hpid | tail -1)
$ grep Groups /proc/$pid/status
Groups: 100038 Pour accéder au périphérique vidéo sur l'hôte, le processus a besoin d'un vrai GID=39 , donc ça échoue. Les utilisateurs sans root ne peuvent pas forcer l'accès au vrai GID=39 sur l'hôte car les protections Linux standard le bloquent.
Podman à la rescousse
Depuis Podman 3.2, nous avons ajouté une nouvelle fonctionnalité, --group-add keep-groups , qui fonctionne avec le runtime OCI crun . Normalement, lorsque vous démarrez un conteneur Podman, le runtime OCI exécute les setgroups appel système ; cela modifie le processus principal à l'intérieur du conteneur pour obtenir les groupes définis dans le conteneur et supprime également l'accès aux groupes de processus parents. Normalement, c'est ce que vous voulez qu'il se passe puisque vous ne voulez pas qu'un processus échappé d'un conteneur ait accès à votre roue groupe, par exemple.
Lorsque vous exécutez avec --group-add keep-groups , le runtime du conteneur OCI (crun ) n'appelle pas les setgroups , de sorte que le nouveau processus conteneur conserve les groupes de son processus parent. Si le processus parent a accès à GID=39 , les processus à l'intérieur du conteneur auront toujours ce groupe et ils pourront utiliser l'appareil.
$ podman run --device /dev/video0 --group-add keep-group … Et tout fonctionne !
[ Vous débutez avec les conteneurs ? Découvrez ce cours gratuit. Déploiement d'applications conteneurisées :présentation technique. ]
Avenant
Notez qu'à l'intérieur du conteneur, le GID 39 n'est pas mappé, donc les processus au sein du conteneur verront cela comme le personne grouper. Il ressemble à ceci :
$ ./bin/podman run --group-add keep-groups fedora groups
root nobody
Les anciennes versions de Podman ont une interface moins conviviale pour déclencher ce comportement dans crun . En ajoutant l'--annotation run.oci.keep_original_groups=1 , crun n'exécutera pas setgroups .
$ podman run --annotation run.oci.keep_original_groups=1 --device /dev/video0
Si vous utilisez le --group-add keep-groups appel, vous ne pouvez pas définir d'autres groupes dans le conteneur. Au lieu de cela, le conteneur ne peut hériter que des groupes du parent. La raison en est que Podman nécessite les setgroups call pour définir des groupes supplémentaires dans le conteneur, ce qui entraînerait la perte de l'accès aux groupes du parent. Giuseppe Scrivano a proposé deux correctifs pour autoriser les setgroups dans cette situation. Cette approche est encore en discussion. Giuseppe a également ouvert un problème avec la spécification d'exécution pour en faire une partie formelle de la spécification et l'intégrer à d'autres runtimes oci comme runc , mais il n'a pas encore fusionné.
Récapitulez
Les utilisateurs de Podman rencontrent un problème pour accéder aux fichiers et aux périphériques dans un conteneur, même lorsque les utilisateurs ont accès à ces ressources sur l'hôte. Nous avons examiné les cas d'utilisation où ce problème est exposé et discuté de certains des correctifs proposés pour résoudre le problème.
[ Télécharger maintenant :Un guide de l'administrateur système sur les scripts Bash. ]