Toolbox: ツールボックスコンテナ内のsudo（8）は、Podman2.0.5でパスワードを要求します

Fedora Workstation32とFedoraWorkstation 33 （仮想マシン上）でいくつかのテストを行い、F32で正常に動作していることを確認できましたが、F33でも同じ問題が発生しました。
だから、これは、Fedora 33自体の問題だけではなく、Silverblueバージョンです。

いくつかのテストの後、私はいくつかの違いに気づきました：

• podmanのバージョンは異なります。
  
  
  
  • 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:::

ツールボックスに入るときのメッセージ（/ usr / bin / id：グループID 1000の名前が見つかりません）がポップアップしないことを除いて、問題はrawhide（F33SB）にまだ存在します。

エラー（/ 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によってない場合にのみトリガーされるという事実によって引き起こされます。 このコードは、ユーザーの作成、正しいグループへの追加、およびユーザーとルートのパスワードの削除を処理します。 init-containerコマンドのコードは、そのような場合でも呼び出されるように少し再構築する必要があると思います。

RawhideのPodmanが道を変えたようです
作成時に--userns = keep-idオプションを処理します
コンテナ。 これで、ユーザーとグループが作成されます。 NS
最初の問題はこの機能に関連しているようです
ユーザーグループには名前がないため、それ自体
正しいGUIDがあるにもかかわらず（私はそれをアップストリームに報告しました：
コンテナ/ podman＃7389）。

実際にはグループを作成していないようです。 そうでなければあなたは名前を持っているでしょう。 ユーザーを作成するだけです。

ホームディレクトリも作成しているのではないでしょうか。 私はそうしないことを望みます。

https://github.com/containers/podman/pull/6829は、問題のあるPodmanの変更でした。

これは、fedora- toolbox： f32imageを使用してSilverblue32で発生してい
ツールボックスのバージョン：0.0.93
podmanバージョン：2.0.5

これは、fedora- toolbox： f32imageを使用してSilverblue32で発生してい
ツールボックスのバージョン：0.0.93
podmanバージョン：2.0.5

ええ、F32の新しいツールボックスインスタンスでSilverblue32に問題があります。 古いツールボックスインスタンスでは引き続き機能しますが、新しい作成では機能しません。 それで、それを「修正」するために行われたことは何でも、F32でそれを壊しました。

ツールボックス0.0.93およびpodman2.0.5を使用するFedora32SBでこの問題を確認できます。

これはFedoraのみに関連するものでも、限定されるものでもありません。Archwithtoolbox0.0.94とpodman2.0.5でも同じ問題が発生します。

これは、fedora- toolbox： f32imageを使用してSilverblue32で発生してい
ツールボックスのバージョン：0.0.93
podmanバージョン：2.0.5

これは、Podman2.0.5がFedora32に組み込まれたためです。

このような回帰をキャッチするために、podmanまたはtoolboxのテストを追加することは可能ですか？ Silverblueは、Toolboxの使用を本当に推奨しています。そのためには、Toolboxはgnome-terminal自体と同じくらい信頼できる必要があります。

podmanまたはtoolboxのテストをに追加することは可能ですか？
このような回帰をキャッチしますか？ シルバーブルーは本当に励まします
1つはToolboxを使用するためのものであり、そのためにはToolboxが必要です。
gnome-terminal自体と同じくらい信頼できること。

Podmanチームに下位互換性を気にかけてもらうこと、または何らかの変更によってToolboxが壊れるかどうかを確認することは、驚くほど困難な戦いであることが証明されています。 @HarryMichalは一貫して破損を追跡し、テストを推進していますが、進捗は遅いです。

podmanまたはtoolboxのテストをに追加することは可能ですか？
このような回帰をキャッチしますか？ シルバーブルーは本当に励まします
1つはToolboxを使用するためのものであり、そのためにはToolboxが必要です。
gnome-terminal自体と同じくらい信頼できること。

Podmanチームに下位互換性を気にかけてもらうこと、または何らかの変更によってToolboxが壊れるかどうかを確認することは、驚くほど困難な戦いであることが証明されています。 @HarryMichalは一貫して破損を追跡し、テストを推進していますが、進捗は遅いです。

この問題を回避する1つの方法は、Silverblueがpodman用に個別のrpmリポジトリを持ち、ツールボックスに対する回帰テストに合格している更新のみを許可することだと思います。

f32アップ​​デートはいつ入手できるのですか？

早く3つの正のカルマに到達します:)

自分で追跡できます-> https://bodhi.fedoraproject.org/updates/FEDORA-2020-306addaac0

このカルマシステムは私にとって新しいものですが、どのように機能しますか？

菩提システムにログインしてアップデートに投票するには、FAS ID（ FedoraアカウントID）が必要です。 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 '| コンテナ内のsudotee -a / etc / groupが修正します。

まだ何が起こっているのですか？ コンテナに入るときにこのエラーが表示されることを意味します。

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

それはhttps://github.com/containers/podman/issues/7389です

/etc/login.defsようなものを正しく考慮しないため、Toolbox自体に同様の回避策を追加することを避けました。

それとも私は誤解しましたか？

@debarshiray ：podmanの問題ポインターをありがとう！ それは確かに根本的な原因のように見えます。 それまでの間、上記の回避策は簡単です。