Toolbox: sudo (8) dentro dos contêineres da caixa de ferramentas pede uma senha com o Podman 2.0.5

Fiz alguns testes no Fedora Workstation 32 e Fedora Workstation 33 (em máquinas virtuais) e posso confirmar que no F32 estava funcionando bem, mas no F33 tive o mesmo problema.
Portanto, este é um problema com o próprio Fedora 33 , não apenas com a versão Silverblue .

Depois de alguns testes, percebi algumas diferenças:

• A versão do podman é diferente.
  
  
  
  • F32 : 2.0.2
  
  
  • F33 : 2.1.0-dev
  
  
• Os arquivos /etc/group e /etc/shadow são diferentes.

No contêiner da caixa de ferramentas no Fedora 33, o usuário não tem seu próprio grupo e ele não está no grupo wheel .
Além disso, o usuário não tem uma entrada no arquivo /etc/shadow e o usuário root tem a senha bloqueada.

A diferença para o arquivo /etc/group (dentro do contêiner) entre o Fedora 32 e o Fedora 33 . O nome de usuário do usuário 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:

A diferença para /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:::

O problema ainda está presente no rawhide (F33SB), com exceção da mensagem ao entrar na caixa de ferramentas (/ usr / bin / id: não é possível encontrar o nome para o ID de grupo 1000) não está mais aparecendo.

Confirmo que também vi um erro (/ usr / bin / id: não é possível encontrar o nome para o ID de grupo 1000), então removi a imagem fedora-toolbox-33 e recriei a caixa de ferramentas, mas agora não posso usar o comando sudo . Estou preso agora.

Acompanho as descobertas que fiz outro dia e consigo fazer com que sudo funcione.

Passos:

(Tudo isso em uma estação de trabalho Fedora 33 em uma VM)

1. Crie o contêiner.

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

1. Entre no container com toolbox e tente o 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: 

Falha! : desapontado:

1. Entre no contêiner com podman :

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

1. Como o usuário não tinha os grupos certos e não estava no arquivo shadow (como mostrei no comentário anterior), apaguei e recriei o usuário, tentando usar os mesmos comandos e parâmetros que toolbox faz (no 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. Entre no contêiner usando toolbox e tente o 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)

Agora funciona! :sorriso:

Conclusão

Algo parece dar errado na geração do usuário, no comando init-container (em algum lugar por aqui ).

Obrigado por relatar isso e tentar encontrar o culpado! Parece que o Podman em Rawhide mudou a maneira como lida com a opção --userns=keep-id ao criar contêineres. Ele cria agora o usuário e o grupo. O primeiro problema parece estar relacionado a essa funcionalidade em si, porque o grupo de usuários não tem um nome, apesar de ter o GUID correto (eu relatei o upstream: https://github.com/containers/podman/issues/7389).

A outra parte (ter que digitar a senha para o sudo) é causada pelo fato de que o caminho do código apontado por @juanje só é disparado se o usuário atual não estiver presente no contêiner. Esse código se encarrega de criar o usuário, adicioná-lo aos grupos corretos e deletar as senhas do usuário e do root. Acho que o código no comando init-container precisa ser um pouco reestruturado para ser chamado mesmo nesses casos.

Parece que Podman em Rawhide mudou a maneira
ele lida com a opção --userns = keep-id ao criar
containers. Ele cria agora o usuário e o grupo. o
o primeiro problema parece estar relacionado a esta funcionalidade
em si porque o grupo de usuários não tem um nome
apesar de ter o GUID correto (eu relatei que upstream:
containers / podman # 7389).

Parece que não é realmente a criação do grupo. Caso contrário, você teria um nome. É apenas criar o usuário.

Eu me pergunto se ele também está criando um diretório inicial. Espero que não.

https://github.com/containers/podman/pull/6829 foi a mudança ofensiva do Podman.

Isso está acontecendo comigo agora no Silverblue 32 usando fedora- toolbox: imagem
versão da caixa de ferramentas: 0.0.93
versão do podman: 2.0.5

Isso está acontecendo comigo agora no Silverblue 32 usando fedora- toolbox: imagem
versão da caixa de ferramentas: 0.0.93
versão do podman: 2.0.5

Sim, eu tenho o problema no Silverblue 32 agora em qualquer nova instância da caixa de ferramentas do F32. Com a antiga instância da caixa de ferramentas, ainda funciona, mas não com novas criações. Então, tudo o que foi feito para "consertar" isso, quebrou em F32.

Pode confirmar este problema no Fedora 32 SB com a caixa de ferramentas 0.0.93 e podman 2.0.5.

Isso não está relacionado ou confinado apenas ao Fedora, o Arch com a caixa de ferramentas 0.0.94 e o podman 2.0.5 têm o mesmo problema.

Isso está acontecendo comigo agora no Silverblue 32 usando fedora- toolbox: imagem
versão da caixa de ferramentas: 0.0.93
versão do podman: 2.0.5

Isso porque o Podman 2.0.5 deslizou para o Fedora 32.

É possível adicionar alguns testes para podman ou caixa de ferramentas para capturar regressões como esta? O Silverblue realmente incentiva o uso do Toolbox e, para que isso aconteça, o Toolbox precisa ser tão confiável quanto o próprio gnome-terminal.

É possível adicionar alguns testes para podman ou caixa de ferramentas para
pegar regressões como esta? Silverblue realmente incentiva
um para usar a caixa de ferramentas, e para que isso aconteça, a caixa de ferramentas precisa
para ser tão confiável quanto o próprio terminal gnome.

Provou ser uma batalha surpreendentemente árdua para fazer a equipe do Podman se preocupar com a compatibilidade com versões anteriores ou para verificar se alguma mudança quebra a caixa de ferramentas ou não. @HarryMichal está constantemente perseguindo quebras e forçando por testes, mas o progresso é lento.

É possível adicionar alguns testes para podman ou caixa de ferramentas para
pegar regressões como esta? Silverblue realmente incentiva
um para usar a caixa de ferramentas, e para que isso aconteça, a caixa de ferramentas precisa
para ser tão confiável quanto o próprio terminal gnome.

Provou ser uma batalha surpreendentemente árdua para fazer a equipe do Podman se preocupar com a compatibilidade com versões anteriores ou para verificar se alguma mudança quebra a caixa de ferramentas ou não. @HarryMichal está constantemente perseguindo quebras e forçando por testes, mas o progresso é lento.

Eu acho que uma maneira de evitar esse problema é Silverblue ter um repositório rpm separado para o podman e apenas todas as atualizações baixas que estão passando nos testes de regressão da caixa de ferramentas

Quando deve chegar às atualizações F32?

Quanto mais cedo atingir 3 carmas positivos :)

Você mesmo pode rastreá-lo -> https://bodhi.fedoraproject.org/updates/FEDORA-2020-306addaac0

Este sistema de carma é novo para mim, como funciona?

Você precisará do ID do FAS (ID da conta do Fedora) para fazer o login no sistema bodhi e votar nas atualizações. Veja https://fedoraproject.org/wiki/Bodhi#Karma

No SilverBlue, posso puxar apenas um determinado pacote e testá-lo? Parece que ele precisa ser refeito para testar um pacote. Qualquer método de teste do pacote (incluindo contêineres, se possível) sem precisar tocar em meu sistema básico é adequado.

No SilverBlue, posso puxar apenas um determinado pacote e testá-lo?
Parece que ele precisa ser refeito para testar um pacote.
Qualquer método de teste do pacote (incluindo recipientes,
se possível) sem precisar tocar meu sistema básico está bem.

rpm-ostree override replace e rpm-ostree override reset são seus amigos.

Infelizmente, você não pode testar coisas como Podman e Toolbox dentro de um contêiner.

Muito obrigado pela solução alternativa @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

A única alteração que fiz para meu usuário em um host Silverblue foi tornar o diretório inicial /var/home/<user>

Isso deve ser reaberto? Definitivamente, ainda está acontecendo com 0.0.95. toolbox create parece colocar o usuário no / etc / passwd do convidado, mas se esquece de copiar a entrada /etc/group . Algo como echo 'martin:x:1000' | sudo tee -a /etc/group no contêiner corrige isso.

Registrei a mesma experiência em https://github.com/containers/toolbox/issues/549#issuecomment -685740230 - comentou lá, pois isso (normalmente) não quebra o sudo.

Definitivamente, ainda está acontecendo com 0.0.95. criar caixa de ferramentas parece
coloque o usuário no / etc / passwd do convidado, mas se esquece
copiando a entrada / etc / group. Algo como
echo ' martin: x : 1000' | sudo tee -a / etc / group no contêiner corrige isso.

O que ainda está acontecendo? Você quer dizer que está vendo este erro ao entrar em um contêiner:

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

Isso é https://github.com/containers/podman/issues/7389

Evitei adicionar uma solução alternativa semelhante ao próprio Toolbox porque ele não levaria em consideração coisas como /etc/login.defs .

Ou eu entendi mal?

@debarshiray : Obrigado pelo indicador de problema do podman! Essa parece ser a causa raiz, de fato. Nesse ínterim, a solução alternativa acima é fácil o suficiente.