Toolbox: 工具箱容器内的 sudo(8) 要求使用 Podman 2.0.5 输入密码

创建于 2020-08-04  ·  26评论  ·  资料来源: containers/toolbox

在F33 Silverblue rawhide上使用toolbox时,输入新创建的toolbox会报错如下...

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

在toolbox里面,发出命令时需要sudoer权限,比如dnf之类的……
sudo dnf install vim-enhanced terminator 会向用户显示以下提示...

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 ssnow:
Sorry, try again.
[sudo] password for ssnow:
Sorry, try again.

这个问题最初是在https://discussion.fedoraproject.org/t/toolbox-and-root/22123/29报告的,我最初认为用户系统必须以某种方式被破坏。 直到我安装了新的生皮版本的 Silverblue。
IMO,它可能与我进入工具箱容器时收到的第一条消息有关。 也许没有将用户映射为容器的根。

最有用的评论

这应该重新开放吗? 0.0.95 肯定仍在发生。 toolbox create似乎将用户放入来宾的 /etc/passwd 中,但忘记复制/etc/group条目。 容器中的echo 'martin:x:1000' | sudo tee -a /etc/group类的东西修复了它。

所有26条评论

我在Fedora Workstation 32Fedora Workstation 33 (在虚拟机上)做了一些测试,我可以确认在 F32 上工作正常,但在 F33 上我遇到了同样的问题。
因此,这是Fedora 33本身的问题,而不仅仅是Silverblue版本。

经过一些测试,我发现了一些差异:

  • podman 的版本是不同的。

    • F322.0.2

    • F332.1.0-dev

  • 文件/etc/group/etc/shadow是不同的。

Fedora 33的工具箱容器中,用户没有自己的组,也不在组wheel
此外,用户在/etc/shadow文件中没有条目并且root用户已锁定密码。

Fedora 32Fedora 33之间/etc/group文件(容器内)的差异。 用户的用户名是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: cannot find name for group ID 1000)。

我确认我也看到了错误(/usr/bin/id:找不到组 ID 1000 的名称)所以我删除了 fedora-toolbox-33 图像并重新创建了工具箱,但现在我不能使用sudo命令。 我现在卡住了。

我跟进了前几天所做的调查结果,并设法让sudo工作。

脚步:

(所有这些都在 VM 中的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命令(在附近的某处)中,用户生成似乎出了点问题。

感谢您报告此事并试图找到罪魁祸首! 似乎 Rawhide 中的 Podman 在创建容器时改变了它处理--userns=keep-id选项的方式。 它现在创建用户和组。 第一个问题似乎与此功能本身有关,因为尽管具有正确的 GUID,但用户组没有名称(我报告了上游:https://github.com/containers/podman/issues/7389)。

另一部分(必须为 sudo 输入密码)是由@juanje指出的代码路径仅在当前用户存在于容器中时才触发的事实引起的。 该代码负责创建用户,将其添加到正确的组并删除用户和 root 的密码。 我认为init-container命令中的代码需要稍微重构一下才能在这种情况下调用。

Rawhide中的Podman似乎改变了方式
它在创建时处理 --userns=keep-id 选项
容器。 它现在创建用户和组。 这
第一个问题似乎与此功能有关
本身因为用户组没有名称
尽管有正确的 GUID(我报告上游:
容器/podman#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

是的,我现在在任何新的 F32 工具箱实例上都有关于 Silverblue 32 的问题。 使用旧的工具箱实例,它仍然有效,但不适用于新的创作。 因此,无论采取什么措施来“修复”它,都会在 F32 上破坏它。

可以使用工具箱 0.0.93 和 podman 2.0.5 在 Fedora 32 SB 上确认此问题。

这不仅与 Fedora 相关或仅限于 Fedora,带有工具箱 0.0.94 和 podman 2.0.5 的 Arch 也有同样的问题。

现在我在 Silverblue 32 上使用 fedora- toolbox:f32 image 发生了这种情况
工具箱版本:0.0.93
播客版本:2.0.5

那是因为 Podman 2.0.5 进入了 Fedora 32。

是否可以为 podman 或工具箱添加一些测试来捕捉这样的回归? Silverblue 真的鼓励人们使用 Toolbox,为此,Toolbox 需要像 gnome-terminal 本身一样可靠。

是否可以为 podman 或工具箱添加一些测试
捕捉这样的回归? Silverblue 真的很鼓励
一个使用 Toolbox,为此 Toolbox 需要
与 gnome-terminal 本身一样可靠。

事实证明,让 Podman 团队关心向后兼容性或检查某些更改是否会破坏 Toolbox 是一场令人惊讶的艰苦战斗。 @HarryMichal一直在追查故障并推动测试,但进展缓慢。

是否可以为 podman 或工具箱添加一些测试
捕捉这样的回归? Silverblue 真的很鼓励
一个使用 Toolbox,为此 Toolbox 需要
与 gnome-terminal 本身一样可靠。

事实证明,让 Podman 团队关心向后兼容性或检查某些更改是否会破坏 Toolbox 是一场令人惊讶的艰苦战斗。 @HarryMichal一直在追查故障并推动测试,但进展缓慢。

我想避免这个问题的一种方法是让 Silverblue 为 podman 提供一个单独的 rpm 存储库,并且只允许通过针对工具箱的回归测试的更新

应该什么时候进行 f32 更新?

它越早达到 3 正业:)

你可以自己跟踪 -> https://bodhi.fedoraproject.org/updates/FEDORA-2020-306addaac0

这个业力系统对我来说是新的,它是如何工作的?

您将需要 FAS id( Fedora 帐户 id)来登录 bodhi 系统并对更新进行投票。 见https://fedoraproject.org/wiki/Bodhi#Karma

在 SilverBlue 上,我可以只提取给定的包并进行测试吗? 似乎需要重新定位以测试包。 无需接触我的基本系统即可测试包(如果可能,包括容器)的任何方法都可以。

在 SilverBlue 上,我可以只提取给定的包并进行测试吗?
似乎需要重新定位以测试包。
任何测试包装的方法(包括容器、
如果可能的话)不需要接触我的基本系统就可以了。

rpm-ostree override replacerpm-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 条目。 就像是
回声'马丁: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 问题指针! 这看起来确实是根本原因。 与此同时,上面的解决方法很容易。

此页面是否有帮助?
0 / 5 - 0 等级