Toolbox: sudo(8) dans les conteneurs de la boîte à outils demande un mot de passe avec Podman 2.0.5

J'ai fait des tests sur Fedora Workstation 32 et Fedora Workstation 33 (sur des machines virtuelles) et je peux confirmer que sur F32 fonctionnait bien, mais sur F33 j'ai eu le même problème.
Il s'agit donc d'un problème avec le Fedora 33 lui-même, pas seulement la version Silverblue .

Après quelques tests, j'ai remarqué quelques différences :

• La version du podman est différente.
  
  
  
  • F32 : 2.0.2
  
  
  • F33 : 2.1.0-dev
  
  
• Les fichiers /etc/group et /etc/shadow sont différents.

Dans le conteneur de la boîte à outils de Fedora 33, l'utilisateur n'a pas son propre groupe et ce n'est pas dans le groupe wheel .
De plus, l'utilisateur n'a pas d'entrée dans le fichier /etc/shadow et l'utilisateur root a le mot de passe verrouillé.

Le diff pour le fichier /etc/group (à l'intérieur du conteneur) entre le Fedora 32 et le Fedora 33 . Le nom d'utilisateur de l'utilisateur était vagrant :

--- f32-image-f33/group 2020-08-14 19:19:38.734363987 +0000
+++ f33-image-f33/group 2020-08-14 19:17:39.018504713 +0000
@@ -8,7 +8,7 @@
 lp:x:7:
 mem:x:8:
 kmem:x:9:
-wheel:x:10:vagrant
+wheel:x:10:
 cdrom:x:11:
 mail:x:12:
 man:x:15:
@@ -26,4 +26,3 @@
 utempter:x:35:
 ssh_keys:x:999:
 tcpdump:x:72:
-vagrant:x:1000:

La différence pour le /etc/shadow :

--- f32-image-f33/shadow    2020-08-14 19:15:25.125242112 +0000
+++ f33-image-f33/shadow    2020-08-14 19:17:11.658920405 +0000
@@ -1,4 +1,4 @@
-root::18488:0:99999:7:::
+root:!locked::0:99999:7:::
 bin:*:18473:0:99999:7:::
 daemon:*:18473:0:99999:7:::
 adm:*:18473:0:99999:7:::
@@ -12,4 +12,3 @@
 ftp:*:18473:0:99999:7:::
 nobody:*:18473:0:99999:7:::
 tcpdump:!!:18481::::::
-vagrant::18488:0:99999:7:::

Le problème est toujours présent dans rawhide (F33SB) à l'exception du message d'entrée dans la boîte à outils (/usr/bin/id : impossible de trouver le nom pour l'ID de groupe 1000) ne s'affiche plus.

Je confirme que j'ai moi aussi vu une erreur (/usr/bin/id: impossible de trouver le nom pour l'ID de groupe 1000), j'ai donc supprimé l'image fedora-toolbox-33 et recréé la boîte à outils, mais je ne peux plus utiliser la commande sudo . Je suis coincé maintenant.

Je fais le suivi des découvertes que j'ai faites l'autre jour et j'arrive à faire fonctionner le sudo .

Pas:

(Tout cela dans un Fedora Workstation 33 dans une VM)

1. Créez le conteneur.

[vagrant@ci-node-33 ~]$ toolbox create
Created container: fedora-toolbox-33
Enter with: toolbox enter

1. Entrez dans le conteneur avec toolbox et essayez la commande sudo :

⬢[vagrant<strong i="18">@toolbox</strong> ~]$ sudo ls

We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:

    #1) Respect the privacy of others.
    #2) Think before you type.
    #3) With great power comes great responsibility.

[sudo] password for vagrant: 

Il échoue! :déçu:

1. Entrez dans le conteneur avec podman :

[vagrant@ci-node-33 ~]$ podman exec -it fedora-toolbox-33 /bin/bash

1. Comme l'utilisateur n'avait pas les bons groupes et que ce n'était pas dans le fichier shadow (comme je l'ai montré dans le commentaire précédent), j'ai supprimé et recréé l'utilisateur, en essayant d'utiliser les mêmes commandes et paramètres que toolbox fait (à la commande init-container ) :

# Delete the user
⬢[root<strong i="32">@toolbox</strong> /]# userdel --force vagrant

# Create the user
⬢[root<strong i="33">@toolbox</strong> /]# useradd --home-dir /home/vagrant/ --no-create-home --shell /bin/bash --uid 1000 --groups wheel vagrant

# Check the user groups (this time are OK)
⬢[root<strong i="34">@toolbox</strong> /]# id vagrant
uid=1000(vagrant) gid=1000(vagrant) groups=1000(vagrant),10(wheel)

# Delete the user password
⬢[root<strong i="35">@toolbox</strong> /]# passwd --delete vagrant
Removing password for user vagrant.
passwd: Note: deleting a password also unlocks the password.
passwd: Success

# Check that the user is at the file /etc/shadow (this is important for PAM authentication and sudo)
⬢[root<strong i="36">@toolbox</strong> /]# grep vagrant /etc/shadow
vagrant::18493:0:99999:7:::

# Logout from the container
⬢[root<strong i="37">@toolbox</strong> /]# exit
[vagrant@ci-node-33 ~]$ 

1. Entrez dans le conteneur en utilisant toolbox et essayez la commande sudo :

[vagrant@ci-node-33 ~]$ toolbox enter
⬢[vagrant<strong i="44">@toolbox</strong> vagrant]$ sudo id

We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:

    #1) Respect the privacy of others.
    #2) Think before you type.
    #3) With great power comes great responsibility.

uid=0(root) gid=0(root) groups=0(root)

Maintenant ça marche! :le sourire:

Conclusion

Quelque chose semble mal tourner au niveau de la génération de l'utilisateur, à la commande init-container (quelque part par ici ).

Merci d'avoir signalé cela et d'avoir essayé de trouver le coupable ! Il semble que Podman à Rawhide ait changé la façon dont il gère l'option --userns=keep-id lors de la création de conteneurs. Il crée maintenant l'utilisateur et le groupe. Le premier problème semble être lié à cette fonctionnalité elle-même car le groupe d'utilisateurs n'a pas de nom malgré le bon GUID (je l'ai signalé en amont : https://github.com/containers/podman/issues/7389).

L'autre partie (avoir à taper le mot de passe pour sudo) est causée par le fait que le chemin de code indiqué par @juanje n'est déclenché que si l'utilisateur actuel n'est pas présent dans le conteneur. Ce code s'occupe de créer l'utilisateur, de l'ajouter aux bons groupes et de supprimer les mots de passe de l'utilisateur et du root. Je pense que le code de la commande init-container doit être un peu restructuré pour être appelé même dans de tels cas.

Il semble que Podman à Rawhide a changé la façon
il gère l'option --userns=keep-id lors de la création
conteneurs. Il crée maintenant l'utilisateur et le groupe. Les
le premier problème semble être lié à cette fonctionnalité
lui-même car le groupe d'utilisateurs n'a pas de nom
malgré le bon GUID (j'ai signalé qu'en amont :
conteneurs/podman#7389).

On dirait que cela ne crée pas réellement le groupe. Sinon tu aurais un nom. Il s'agit simplement de créer l'utilisateur.

Je me demande s'il crée également un répertoire personnel. J'espère que non.

https://github.com/containers/podman/pull/6829 était le changement de Podman incriminé.

Cela se produit pour moi maintenant sur Silverblue 32 en utilisant fedora- toolbox:f32 image
version de la boîte à outils : 0.0.93
version de podman : 2.0.5

Cela se produit pour moi maintenant sur Silverblue 32 en utilisant fedora- toolbox:f32 image
version de la boîte à outils : 0.0.93
version de podman : 2.0.5

Oui, j'ai maintenant le problème sur Silverblue 32 sur toute nouvelle instance de boîte à outils de F32. Avec l'ancienne instance de la boîte à outils, cela fonctionne toujours, mais pas avec les nouvelles créations. Donc, tout ce qui a été fait pour le "réparer", l'a cassé sur F32.

Peut confirmer ce problème sur Fedora 32 SB avec toolbox 0.0.93 et ​​podman 2.0.5.

Ce n'est pas lié ou limité à Fedora uniquement, Arch avec toolbox 0.0.94 et podman 2.0.5 a le même problème.

Cela se produit pour moi maintenant sur Silverblue 32 en utilisant fedora- toolbox:f32 image
version de la boîte à outils : 0.0.93
version de podman : 2.0.5

C'est parce que Podman 2.0.5 s'est glissé dans Fedora 32.

Est-il possible d'ajouter des tests pour podman ou toolbox pour attraper des régressions comme celle-ci ? Silverblue encourage vraiment à utiliser Toolbox, et pour cela, Toolbox doit être aussi fiable que gnome-terminal lui-même.

Est-il possible d'ajouter des tests pour podman ou toolbox à
attraper des régressions comme celle-ci ? Silverblue encourage vraiment
un pour utiliser Toolbox, et pour que cela se produise, Toolbox a besoin
être aussi fiable que gnome-terminal lui-même.

Il s'est avéré être une bataille étonnamment difficile pour amener l'équipe Podman à se soucier de la rétrocompatibilité ou pour vérifier si un changement casse ou non Toolbox. @HarryMichal poursuit constamment les

Est-il possible d'ajouter des tests pour podman ou toolbox à
attraper des régressions comme celle-ci ? Silverblue encourage vraiment
un pour utiliser Toolbox, et pour que cela se produise, Toolbox a besoin
être aussi fiable que gnome-terminal lui-même.

Il s'est avéré être une bataille étonnamment difficile pour amener l'équipe Podman à se soucier de la rétrocompatibilité ou pour vérifier si un changement casse ou non Toolbox. @HarryMichal poursuit constamment les

Je suppose qu'une façon d'éviter ce problème est que Silverblue ait un dépôt rpm séparé pour podman et n'autorise que les mises à jour qui réussissent les tests de régression par rapport à la boîte à outils

Quand est-il censé arriver aux mises à jour f32 ?

Plus vite il atteindra 3 karma positif :)

Vous pouvez le suivre vous-même -> https://bodhi.fedoraproject.org/updates/FEDORA-2020-306addaac0

Ce système de karma est nouveau pour moi, comment ça marche ?

Vous aurez besoin de l'identifiant FAS (identifiant du compte Fedora) pour vous connecter au système bodhi et voter sur les mises à jour. Voir https://fedoraproject.org/wiki/Bodhi#Karma

Sur SilverBlue, puis-je extraire uniquement un package donné et le tester ? Il semble qu'il doit être rebasé pour tester un package. Toute méthode de test du package (y compris les conteneurs, si possible) sans avoir besoin de toucher mon système de base convient.

Sur SilverBlue, puis-je extraire uniquement un package donné et le tester ?
Il semble qu'il doit être rebasé pour tester un package.
Toute méthode de test de l'emballage (y compris les conteneurs,
si possible) sans avoir besoin de toucher mon système de base est très bien.

rpm-ostree override replace et rpm-ostree override reset sont vos amis.

Malheureusement, vous ne pouvez pas tester des choses comme Podman et Toolbox à l'intérieur d'un conteneur.

Merci beaucoup pour la solution de contournement @juanje

# Create the user
⬢[root<strong i="7">@toolbox</strong> /]# useradd --home-dir /home/vagrant/ --no-create-home --shell /bin/bash --uid 1000 --groups wheel vagrant

Le seul changement que j'ai apporté à mon utilisateur sur un hôte Silverblue a été de créer le répertoire personnel /var/home/<user>

Faut-il rouvrir celui-ci ? Définitivement toujours en cours avec 0.0.95. toolbox create semble bien mettre l'utilisateur dans le /etc/passwd de l'invité, mais oublie de copier l'entrée /etc/group . Quelque chose comme echo 'martin:x:1000' | sudo tee -a /etc/group dans le conteneur le résout.

J'ai enregistré la même expérience dans https://github.com/containers/toolbox/issues/549#issuecomment -685740230 -- commenté là-bas car cela ne casse pas (généralement) sudo.

Définitivement toujours en cours avec 0.0.95. la création de la boîte à outils semble
mettre l'utilisateur dans le /etc/passwd de l'invité bien, mais oublie
copier l'entrée /etc/group. Quelque chose comme
echo ' martin:x :1000' | sudo tee -a /etc/group dans le conteneur le corrige.

Que se passe-t-il encore ? Vous voulez dire que vous voyez cette erreur lors de la saisie d'un conteneur :

/usr/bin/id: cannot find name for group ID 1000

C'est https://github.com/containers/podman/issues/7389

J'ai évité d'ajouter une solution de contournement similaire à Toolbox elle-même, car elle ne prendrait pas correctement en compte des éléments tels que /etc/login.defs .

Ou ai-je mal compris ?

@debarshiray : Merci pour le pointeur du problème podman ! Cela ressemble en effet à la cause première. En attendant, la solution de contournement ci-dessus est assez simple.