Toolbox: sudo(8) in Toolbox-Containern fragt nach einem Passwort mit Podman 2.0.5

Ich habe einige Tests mit Fedora Workstation 32 und Fedora Workstation 33 (auf virtuellen Maschinen) durchgeführt und kann bestätigen, dass F32 gut funktioniert hat, aber bei F33 habe ich das gleiche Problem.
Dies ist also ein Problem mit dem Fedora 33 selbst, nicht nur mit der Silverblue- Version.

Nach einigen Tests habe ich einige Unterschiede festgestellt:

• Die Version des Podman ist anders.
  
  
  
  • F32 : 2.0.2
  
  
  • F33 : 2.1.0-dev
  
  
• Die Dateien /etc/group und /etc/shadow sind unterschiedlich.

Beim Toolbox-Container in Fedora 33 hat der Benutzer keine eigene Gruppe und ist nicht in der Gruppe wheel .
Außerdem hat der Benutzer keinen Eintrag in der Datei /etc/shadow und der Benutzer root hat das Kennwort gesperrt.

Der Diff für die Datei /etc/group (im Container) zwischen Fedora 32 und Fedora 33 . Der Benutzername für den Benutzer war 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:

Der Diff für die /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:::

Das Problem ist in Rawhide (F33SB) immer noch vorhanden, mit Ausnahme der Meldung beim Betreten der Toolbox (/usr/bin/id: kann den Namen für die Gruppen-ID 1000 nicht finden) wird nicht mehr angezeigt.

Ich bestätige, dass ich auch einen Fehler gesehen habe (/usr/bin/id: kann den Namen für die Gruppen-ID 1000 nicht finden), also habe ich das Fedora-Toolbox-33-Image entfernt und die Toolbox neu erstellt, aber jetzt kann ich den Befehl sudo nicht verwenden. Ich stecke jetzt fest.

Ich folge den Ergebnissen, die ich neulich gemacht habe, und schaffe es, die sudo Laufen zu bringen.

Schritte:

(All dies in einer Fedora Workstation 33 in einer VM)

1. Erstellen Sie den Container.

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

1. Geben Sie mit toolbox in den Container ein und versuchen Sie den Befehl 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: 

Es schlägt fehl! :enttäuscht:

1. Geben Sie mit podman in den Container ein:

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

1. Da der Benutzer nicht die richtigen Gruppen hatte und er sich nicht in der Datei shadow (wie ich im vorherigen Kommentar gezeigt habe), habe ich den Benutzer gelöscht und neu erstellt und versucht, die gleichen Befehle zu verwenden und Parameter, die toolbox tut (beim init-container Befehl):

# 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. Betreten Sie den Container mit toolbox und versuchen Sie den Befehl 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)

Jetzt gehts! :Lächeln:

Abschluss

Etwas scheint bei der Benutzergenerierung, beim init-container Befehl (irgendwo hier ) schief zu gehen.

Vielen Dank, dass Sie dies gemeldet und versucht haben, den Täter zu finden! Es scheint, dass Podman in Rawhide die Art und Weise geändert hat, wie es die Option --userns=keep-id beim Erstellen von Containern behandelt. Es erstellt nun den Benutzer und die Gruppe. Das erste Problem scheint mit dieser Funktionalität selbst zusammenzuhängen, da die Benutzergruppe trotz korrekter GUID keinen Namen hat (ich habe den Upstream gemeldet: https://github.com/containers/podman/issues/7389).

Der andere Teil (Passwort für sudo eingeben zu müssen) wird dadurch verursacht, dass der von @juanje angegebene Codepfad nur ausgelöst wird, wenn der aktuelle Benutzer nicht im Container vorhanden ist. Dieser Code kümmert sich um das Erstellen des Benutzers, das Hinzufügen zu den richtigen Gruppen und das Löschen von Passwörtern für Benutzer und Root. Ich denke, der Code im Befehl init-container muss etwas umstrukturiert werden, um auch in solchen Fällen aufgerufen zu werden.

Es scheint, dass Podman in Rawhide den Weg geändert hat
es behandelt die Option --userns=keep-id beim Erstellen
Behälter. Es erstellt nun den Benutzer und die Gruppe. Die
Das erste Problem scheint mit dieser Funktionalität zusammenzuhängen
sich selbst, weil die Benutzergruppe keinen Namen hat
obwohl ich die richtige GUID habe (ich habe den Upstream gemeldet:
container/podman#7389).

Es scheint, als ob die Gruppe nicht wirklich erstellt wird. Sonst hättest du einen Namen. Es wird nur der Benutzer erstellt.

Ich frage mich, ob es auch ein Home-Verzeichnis erstellt. Ich hoffe nicht.

https://github.com/containers/podman/pull/6829 war die beleidigende Podman-Änderung.

Dies geschieht bei mir jetzt auf Silverblue 32 mit fedora- toolbox:f32 image
Toolbox-Version: 0.0.93
Podman-Version: 2.0.5

Dies geschieht bei mir jetzt auf Silverblue 32 mit fedora- toolbox:f32 image
Toolbox-Version: 0.0.93
Podman-Version: 2.0.5

Ja, ich habe das Problem mit Silverblue 32 jetzt bei jeder neuen Toolbox-Instanz von F32. Mit der alten Toolbox-Instanz funktioniert es noch, aber nicht mit neuen Kreationen. Was auch immer getan wurde, um es zu "reparieren", hat es bei F32 kaputt gemacht.

Kann dieses Problem auf Fedora 32 SB mit Toolbox 0.0.93 und Podman 2.0.5 bestätigen.

Dies ist nicht nur auf Fedora bezogen oder beschränkt, Arch mit Toolbox 0.0.94 und Podman 2.0.5 hat das gleiche Problem.

Dies geschieht bei mir jetzt auf Silverblue 32 mit fedora- toolbox:f32 image
Toolbox-Version: 0.0.93
Podman-Version: 2.0.5

Das liegt daran, dass Podman 2.0.5 in Fedora 32 gerutscht ist.

Ist es möglich, einige Tests für Podman oder Toolbox hinzuzufügen, um solche Regressionen zu erkennen? Silverblue ermutigt einen wirklich, Toolbox zu verwenden, und dafür muss Toolbox so zuverlässig sein wie gnome-terminal selbst.

Ist es möglich, einige Tests für Podman oder Toolbox hinzuzufügen?
Regressionen wie diese fangen? Silverblue macht wirklich Mut
eine, um Toolbox zu verwenden, und dafür benötigt Toolbox
so zuverlässig wie gnome-terminal selbst zu sein.

Es hat sich als überraschend harter Kampf erwiesen, das Podman-Team dazu zu bringen, sich um die Abwärtskompatibilität zu kümmern oder zu überprüfen, ob eine Änderung die Toolbox beschädigt oder nicht. @HarryMichal jagt konsequent Brüche und drängt auf Tests, aber der Fortschritt ist langsam.

Ist es möglich, einige Tests für Podman oder Toolbox hinzuzufügen?
Regressionen wie diese fangen? Silverblue macht wirklich Mut
eine, um Toolbox zu verwenden, und dafür benötigt Toolbox
so zuverlässig wie gnome-terminal selbst zu sein.

Es hat sich als überraschend harter Kampf erwiesen, das Podman-Team dazu zu bringen, sich um die Abwärtskompatibilität zu kümmern oder zu überprüfen, ob eine Änderung die Toolbox beschädigt oder nicht. @HarryMichal jagt konsequent Brüche und drängt auf Tests, aber der Fortschritt ist langsam.

Ich denke, eine Möglichkeit, dieses Problem zu vermeiden, besteht darin, dass Silverblue ein separates RPM-Repository für Podman hat und nur Updates zulässt, die Regressionstests gegen die Toolbox bestehen

Wann soll es zu f32-Updates kommen?

Je eher es 3 positives Karma erreicht :)

Sie können es selbst verfolgen -> https://bodhi.fedoraproject.org/updates/FEDORA-2020-306addaac0

Dieses Karma-System ist neu für mich, wie funktioniert es?

Sie benötigen die FAS-ID ( Fedora-Konto-ID) , um sich beim Bodhi-System anzumelden und Ihre Stimme für die Aktualisierungen abzugeben. Siehe https://fedoraproject.org/wiki/Bodhi#Karma

Kann ich bei SilverBlue nur ein bestimmtes Paket ziehen und testen? Es scheint, dass es umbasiert werden muss, um ein Paket zu testen. Jede Methode zum Testen des Pakets (einschließlich Container, wenn möglich), ohne mein Basissystem berühren zu müssen, ist in Ordnung.

Kann ich bei SilverBlue nur ein bestimmtes Paket ziehen und testen?
Es scheint, dass es umbasiert werden muss, um ein Paket zu testen.
Jede Methode zum Testen des Pakets (einschließlich Container,
wenn möglich), ohne dass ich mein Basissystem berühren muss, ist in Ordnung.

rpm-ostree override replace und rpm-ostree override reset sind deine Freunde.

Leider können Sie Dinge wie Podman und Toolbox nicht in einem Container testen.

Vielen Dank für die Problemumgehung @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

Die einzige Änderung, die ich für meinen Benutzer auf einem Silverblue-Host vorgenommen habe, bestand darin, das Home-Verzeichnis zu /var/home/<user>

Soll das wieder geöffnet werden? Definitiv noch passiert mit 0.0.95. toolbox create scheint den Benutzer in die /etc/passwd des Gastes zu bringen, vergisst aber das Kopieren des /etc/group Eintrags. Etwas wie echo 'martin:x:1000' | sudo tee -a /etc/group im Container behebt das Problem.

Habe die gleiche Erfahrung in https://github.com/containers/toolbox/issues/549#issuecomment -685740230 aufgezeichnet – dort kommentiert, da dies (normalerweise) kein Sudo unterbricht.

Definitiv noch passiert mit 0.0.95. Toolbox erstellen scheint
füge den Benutzer in das /etc/passwd des Gastes ein, gut, aber vergisst es
Kopieren des /etc/group-Eintrags. Etwas wie
echo ' martin:x :1000' | sudo tee -a /etc/group im Container behebt das Problem.

Was passiert noch? Sie meinen, dass Sie diesen Fehler sehen, wenn Sie einen Container eingeben:

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

Das ist https://github.com/containers/podman/issues/7389

Ich habe mich davor gescheut, Toolbox selbst eine ähnliche Problemumgehung hinzuzufügen, da sie Dinge wie /etc/login.defs nicht korrekt berücksichtigen würde.

Oder habe ich das falsch verstanden?

@debarshiray : Danke für den Hinweis auf das Podman-Problem! Das sieht tatsächlich nach der Hauptursache aus. In der Zwischenzeit ist die obige Problemumgehung einfach genug.