Toolbox: sudo (8) внутри контейнеров Toolbox запрашивает пароль с Podman 2.0.5

Я провел некоторое тестирование на Fedora Workstation 32 и Fedora Workstation 33 (на виртуальных машинах) и могу подтвердить, что на F32 все работает нормально, но на F33 у меня возникла та же проблема.
Итак, это проблема самой Fedora 33 , а не только версии Silverblue .

После некоторого тестирования я заметил некоторые отличия:

• Версия подмана другая.
  
  
  
  • F32 : 2.0.2
  
  
  • F33 : 2.1.0-dev
  
  
• Файлы /etc/group и /etc/shadow разные.

В контейнере панели инструментов в Fedora 33 у пользователя нет собственной группы, и он не находится в группе wheel .
Кроме того, у пользователя нет записи в файле /etc/shadow а у пользователя root пароль заблокирован.

Разница для файла /etc/group (внутри контейнера) между Fedora 32 и Fedora 33 . Имя пользователя для пользователя было 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:

Разница для /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:::

Проблема все еще присутствует в rawhide (F33SB), за исключением того, что сообщение при входе в панель инструментов (/ usr / bin / id: не удается найти имя для идентификатора группы 1000) больше не появляется.

Я подтверждаю, что я тоже видел ошибку (/ usr / bin / id: не могу найти имя для идентификатора группы 1000), поэтому я удалил изображение fedora-toolbox-33 и повторно создал набор инструментов, но теперь я не могу использовать команду sudo . Я застрял.

Я отслеживаю результаты, которые сделал на днях, и мне удалось заставить sudo работать.

Шаги:

(Все это на Fedora Workstation 33 в виртуальной машине)

1. Создайте контейнер.

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

1. Войдите в контейнер с помощью toolbox и попробуйте команду 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: 

Это не удается! :расстроенный:

1. Введите в контейнер с podman :

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

1. Поскольку у пользователя не было нужных групп и его не было в файле shadow (как я показал в предыдущем комментарии), я удалил и заново создал пользователя, пытаясь использовать те же команды и параметры, которые выполняет toolbox (в команде 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. Войдите в контейнер с помощью toolbox и попробуйте команду 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)

Теперь это работает! :улыбка:

Заключение

Что-то пошло не так при генерации пользователей при выполнении команды init-container (где-то здесь ).

Спасибо, что сообщили об этом и попытались найти виновника! Похоже, что Podman в Rawhide изменил способ обработки параметра --userns=keep-id при создании контейнеров. Теперь он создает пользователя и группу. Первая проблема, похоже, связана с самой этой функциональностью, потому что у группы пользователей нет имени, несмотря на наличие правильного GUID (я сообщил об этом в восходящем направлении: https://github.com/containers/podman/issues/7389).

Другая часть (имея в типе пароль для Судо) обусловлена тем , что путь кода указывал на @juanje включается только если текущий пользователь не присутствует в контейнере. Этот код заботится о создании пользователя, добавлении его в нужные группы и удалении паролей для пользователя и root. Я думаю, что код в команде init-container нужно немного реструктурировать, чтобы его можно было вызывать даже в таких случаях.

Похоже, что Подман в Rawhide изменил образ жизни
он обрабатывает параметр --userns = keep-id при создании
контейнеры. Теперь он создает пользователя и группу. В
первая проблема, похоже, связана с этой функциональностью
сама, потому что у группы пользователей нет имени
несмотря на то, что у меня правильный GUID (я сообщил, что восходящий поток:
контейнеры / подман №7389).

Похоже, на самом деле это не создание группы. В противном случае у тебя было бы имя. Это просто создание пользователя.

Интересно, создает ли он также домашний каталог. Надеюсь нет.

https://github.com/containers/podman/pull/6829 было оскорбительным изменением Podman.

Это происходит сейчас со мной на Silverblue 32 с использованием fedora- toolbox : f32 image
версия панели инструментов: 0.0.93
версия подмана: 2.0.5

Это происходит сейчас со мной на Silverblue 32 с использованием fedora- toolbox : f32 image
версия панели инструментов: 0.0.93
версия подмана: 2.0.5

Да, у меня проблема с Silverblue 32 сейчас на любом новом экземпляре панели инструментов F32. Со старым экземпляром набора инструментов он все еще работает, но не с новыми творениями. Итак, все, что было сделано, чтобы «исправить» это, сломалось на F32.

Можно подтвердить эту проблему в Fedora 32 SB с набором инструментов 0.0.93 и podman 2.0.5.

Это не связано и не ограничивается только Fedora, Arch с Toolbox 0.0.94 и podman 2.0.5 имеют ту же проблему.

Это происходит сейчас со мной на Silverblue 32 с использованием fedora- toolbox : f32 image
версия панели инструментов: 0.0.93
версия подмана: 2.0.5

Это потому, что Podman 2.0.5 переместился в Fedora 32.

Можно ли добавить тесты для podman или toolbox, чтобы отловить подобные регрессии? Silverblue действительно поощряет использование Toolbox, и для этого Toolbox должен быть таким же надежным, как и сам gnome-terminal.

Можно ли добавить тесты для podman или toolbox в
поймать такие регрессии? Silverblue действительно поощряет
один для использования Toolbox, и для этого Toolbox необходимо
быть таким же надежным, как сам gnome-terminal.

На удивление нелегко было заставить команду Podman позаботиться об обратной совместимости или проверить, нарушает ли Toolbox какое-то изменение. @HarryMichal постоянно требует тестов, но прогресс идет медленно.

Можно ли добавить тесты для podman или toolbox в
поймать такие регрессии? Silverblue действительно поощряет
один для использования Toolbox, и для этого Toolbox необходимо
быть таким же надежным, как сам gnome-terminal.

На удивление нелегко было заставить команду Podman позаботиться об обратной совместимости или проверить, нарушает ли Toolbox какое-то изменение. @HarryMichal постоянно требует тестов, но прогресс идет медленно.

Я предполагаю, что один из способов избежать этой проблемы состоит в том, чтобы Silverblue иметь отдельное репозиторий rpm для podman и только все медленные обновления, которые проходят регрессионные тесты на панели инструментов.

Когда должно дойти до апдейтов f32?

Чем раньше дойдет до 3-х положительных карм :)

Вы можете отследить это сами -> https://bodhi.fedoraproject.org/updates/FEDORA-2020-306addaac0

Эта система кармы для меня нова, как она работает?

Вам понадобится идентификатор FAS (идентификатор учетной записи Fedora), чтобы войти в систему bodhi и проголосовать за обновления. См. Https://fedoraproject.org/wiki/Bodhi#Karma

Могу ли я вытащить на SilverBlue только данный пакет и протестировать его? Кажется, его нужно переустановить, чтобы протестировать пакет. Подойдет любой метод тестирования пакета (включая контейнеры, если это возможно) без необходимости касаться моей базовой системы.

Могу ли я вытащить на SilverBlue только данный пакет и протестировать его?
Кажется, его нужно переустановить, чтобы протестировать пакет.
Любой метод тестирования упаковки (включая тару,
если возможно) без необходимости прикасаться к моей базовой системе.

rpm-ostree override replace и rpm-ostree override reset - ваши друзья.

К сожалению, вы не можете протестировать такие вещи, как Podman и Toolbox, внутри контейнера.

Большое спасибо за обходной путь @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

Единственное изменение, которое я сделал для своего пользователя на хосте Silverblue, - это создание домашнего каталога /var/home/<user>

Следует ли его снова открыть? Окончательно все еще происходит с 0.0.95. toolbox create похоже, правильно помещает пользователя в гостевой / etc / passwd, но забывает о копировании записи /etc/group . Что-то вроде echo 'martin:x:1000' | sudo tee -a /etc/group в контейнере исправляет.

Записали тот же опыт в https://github.com/containers/toolbox/issues/549#issuecomment -685740230 - прокомментировал там, поскольку это (обычно) не нарушает sudo.

Окончательно все еще происходит с 0.0.95. набор инструментов создать кажется
поместите пользователя в гостевой / etc / passwd хорошо, но забывает о
копирование записи / etc / group. Что-то вроде
echo ' martin: x : 1000' | sudo tee -a / etc / group в контейнере исправляет это.

Что еще происходит? Вы имеете в виду, что видите эту ошибку при входе в контейнер:

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

Это https://github.com/containers/podman/issues/7389

Я уклонился от добавления аналогичного обходного пути в сам Toolbox, потому что он не учитывал бы такие вещи, как /etc/login.defs .

Или я неправильно понял?

@debarshiray : Спасибо за указатель на выпуск podman! Это действительно похоже на первопричину. Между тем, описанный выше обходной путь достаточно прост.