Toolbox: sudo (8) dentro de los contenedores de la caja de herramientas solicita una contraseña con Podman 2.0.5

Hice algunas pruebas en Fedora Workstation 32 y Fedora Workstation 33 (en máquinas virtuales) y puedo confirmar que en F32 funcionaba bien, pero en F33 tuve el mismo problema.
Entonces, este es un problema con el propio Fedora 33 , no solo con la versión Silverblue .

Después de algunas pruebas, noté algunas diferencias:

• La versión del podman es diferente.
  
  
  
  • F32 : 2.0.2
  
  
  • F33 : 2.1.0-dev
  
  
• Los archivos /etc/group y /etc/shadow son diferentes.

En el contenedor de la caja de herramientas en Fedora 33, el usuario no tiene su propio grupo y no está en el grupo wheel .
Además, el usuario no tiene una entrada en el archivo /etc/shadow y el usuario root tiene la contraseña bloqueada.

La diferencia para el archivo /etc/group (dentro del contenedor) entre Fedora 32 y Fedora 33 . El nombre de usuario del usuario era 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 diferencia para el /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:::

El problema aún está presente en rawhide (F33SB) con la excepción del mensaje al ingresar a la caja de herramientas (/ usr / bin / id: no se puede encontrar el nombre para el ID de grupo 1000) ya no aparece.

Confirmo que yo también vi el error (/ usr / bin / id: no puedo encontrar el nombre para el ID de grupo 1000), así que eliminé la imagen fedora-toolbox-33 y volví a crear la caja de herramientas, pero ahora no puedo usar el comando sudo . Estoy atascado ahora.

Continúo con los hallazgos que hice el otro día y me las arreglo para que funcione el sudo .

Pasos:

(Todo esto en una Workstation 33 de Fedora en una VM)

1. Crea el contenedor.

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

1. Ingrese al contenedor con toolbox y pruebe el comando 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: 

¡Fracasa! :decepcionado:

1. Ingrese al contenedor con podman :

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

1. Como el usuario no tenía los grupos correctos y no estaba en el archivo shadow (como mostré en el comentario anterior), eliminé y recreé al usuario, tratando de usar los mismos comandos y parámetros que hace toolbox (en el comando 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. Ingrese al contenedor usando toolbox y pruebe el comando 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)

¡Ahora funciona! :sonrisa:

Conclusión

Algo parece salir mal en la generación de usuarios, en el comando init-container (en algún lugar por aquí ).

Gracias por informar de esto y tratar de encontrar al culpable. Parece que Podman en Rawhide cambió la forma en que maneja la opción --userns=keep-id al crear contenedores. Crea ahora el usuario y el grupo. El primer problema parece estar relacionado con esta funcionalidad en sí porque el grupo de usuarios no tiene un nombre a pesar de tener el GUID correcto (lo informé anteriormente: https://github.com/containers/podman/issues/7389).

La otra parte (tener que escribir la contraseña para sudo) se debe al hecho de que la ruta del código señalada por @juanje solo se activa si el usuario actual no está presente en el contenedor. Ese código se encarga de crear el usuario, agregarlo a los grupos correctos y eliminar las contraseñas del usuario y root. Creo que el código en el comando init-container necesita ser reestructurado un poco para ser llamado incluso en tales casos.

Parece que Podman en Rawhide cambió la forma
maneja la opción --userns = keep-id al crear
contenedores. Crea ahora el usuario y el grupo. los
El primer problema parece estar relacionado con esta funcionalidad.
en sí mismo porque el grupo de usuarios no tiene un nombre
a pesar de tener el GUID correcto (lo informé en sentido ascendente:
contenedores / podman # 7389).

Parece que en realidad no está creando el grupo. De lo contrario, tendrías un nombre. Es solo crear al usuario.

Me pregunto si también está creando un directorio de inicio. Espero que no.

https://github.com/containers/podman/pull/6829 fue el cambio ofensivo de Podman.

Esto me está sucediendo ahora en Silverblue 32 usando fedora- caja de herramientas: imagen
versión de la caja de herramientas: 0.0.93
versión de podman: 2.0.5

Esto me está sucediendo ahora en Silverblue 32 usando fedora- caja de herramientas: imagen
versión de la caja de herramientas: 0.0.93
versión de podman: 2.0.5

Sí, tengo el problema en Silverblue 32 ahora en cualquier nueva instancia de caja de herramientas de F32. Con la instancia de la caja de herramientas antigua, todavía funciona, pero no con las nuevas creaciones. Entonces, cualquier cosa que se haya hecho para "arreglarlo", lo rompió en F32.

Puede confirmar este problema en Fedora 32 SB con toolbox 0.0.93 y podman 2.0.5.

Esto no está relacionado ni se limita solo a Fedora, Arch con caja de herramientas 0.0.94 y podman 2.0.5 tiene el mismo problema.

Esto me está sucediendo ahora en Silverblue 32 usando fedora- caja de herramientas: imagen
versión de la caja de herramientas: 0.0.93
versión de podman: 2.0.5

Eso es porque Podman 2.0.5 se deslizó en Fedora 32.

¿Es posible agregar algunas pruebas para podman o toolbox para detectar regresiones como esta? Silverblue realmente anima a uno a usar Toolbox, y para que eso suceda, Toolbox necesita ser tan confiable como el propio gnome-terminal.

¿Es posible agregar algunas pruebas para podman o toolbox a
captar regresiones como esta? Silverblue realmente anima
uno para usar Toolbox, y para que eso suceda, Toolbox necesita
para ser tan confiable como el propio gnome-terminal.

Ha demostrado ser una batalla sorprendentemente cuesta arriba conseguir que el equipo de Podman se preocupe por la compatibilidad con versiones anteriores o comprobar si algún cambio rompe Toolbox o no. @HarryMichal está constantemente persiguiendo roturas y presionando para que se

¿Es posible agregar algunas pruebas para podman o toolbox a
captar regresiones como esta? Silverblue realmente anima
uno para usar Toolbox, y para que eso suceda, Toolbox necesita
para ser tan confiable como el propio gnome-terminal.

Ha demostrado ser una batalla sorprendentemente cuesta arriba conseguir que el equipo de Podman se preocupe por la compatibilidad con versiones anteriores o comprobar si algún cambio rompe Toolbox o no. @HarryMichal está constantemente persiguiendo roturas y presionando para que se

Supongo que una forma de evitar este problema es que Silverblue tenga un repositorio de rpm separado para podman y solo todas las actualizaciones bajas que pasen las pruebas de regresión contra la caja de herramientas

¿Cuándo se supone que llegará a las actualizaciones de f32?

Cuanto antes llegue a 3 karmas positivos :)

Puede rastrearlo usted mismo -> https://bodhi.fedoraproject.org/updates/FEDORA-2020-306addaac0

Este sistema de karma es nuevo para mí, ¿cómo funciona?

Necesitará la identificación de FAS (identificación de la cuenta de Fedora) para iniciar sesión en el sistema bodhi y proporcionar su voto sobre las actualizaciones. Ver https://fedoraproject.org/wiki/Bodhi#Karma

En SilverBlue, ¿puedo extraer solo un paquete determinado y probarlo? Parece que es necesario modificar su base para probar un paquete. Cualquier método para probar el paquete (incluidos los contenedores, si es posible) sin necesidad de tocar mi sistema base está bien.

En SilverBlue, ¿puedo extraer solo un paquete determinado y probarlo?
Parece que es necesario modificar su base para probar un paquete.
Cualquier método de prueba del paquete (incluidos contenedores,
si es posible) sin necesidad de tocar mi sistema base está bien.

rpm-ostree override replace y rpm-ostree override reset son tus amigos.

Desafortunadamente, no puede probar cosas como Podman y Toolbox dentro de un contenedor.

Muchas gracias por la solución @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

El único cambio que hice para mi usuario en un host Silverblue fue hacer que el directorio de inicio /var/home/<user>

¿Debería reabrirse? Definitivamente sigue sucediendo con 0.0.95. toolbox create parece poner al usuario en el / etc / passwd del invitado, pero se olvida de copiar la entrada /etc/group . Algo como echo 'martin:x:1000' | sudo tee -a /etc/group en el contenedor lo corrige.

He registrado la misma experiencia en https://github.com/containers/toolbox/issues/549#issuecomment -685740230 - comentado allí ya que esto (generalmente) no rompe sudo.

Definitivamente sigue sucediendo con 0.0.95. la creación de la caja de herramientas parece
poner al usuario en / etc / passwd del invitado, pero se olvida de
copiando la entrada / etc / group. Algo como
echo ' martin: x : 1000' | sudo tee -a / etc / group en el contenedor lo corrige.

¿Qué sigue pasando? Quiere decir que está viendo este error al ingresar a un contenedor:

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

Eso es https://github.com/containers/podman/issues/7389

Evité agregar una solución similar a Toolbox porque no tendría en cuenta correctamente cosas como /etc/login.defs .

¿O lo entendí mal?

@debarshiray : ¡Gracias por el puntero del problema de podman! Eso parece ser la causa raíz. Mientras tanto, la solución anterior es bastante fácil.