Toolbox: يطلب sudo (8) داخل حاويات صندوق الأدوات كلمة مرور باستخدام Podman 2.0.5

لقد أجريت بعض الاختبارات على Fedora Workstation 32 و Fedora Workstation 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:::

لا تزال المشكلة موجودة في المخبأ (F33SB) باستثناء الرسالة عند إدخال مربع الأدوات (/ usr / bin / id: لا يمكن العثور على اسم معرف المجموعة 1000) لم تعد تظهر.

أؤكد أنني رأيت أيضًا خطأ (/ usr / bin / id: لا يمكنني العثور على اسم لمعرف المجموعة 1000) لذلك قمت بإزالة صورة fedora-toolbox-33 وأعدت إنشاء مربع الأدوات ولكن الآن لا يمكنني استخدام الأمر sudo . أنا عالق الآن.

أتابع النتائج التي توصلت إليها في اليوم الآخر وتمكنت من الحصول على عمل sudo .

خطوات:

(كل هذا في محطة عمل Fedora 33 في VM)

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 in Rawhide قد غير الطريقة التي يتعامل بها مع خيار --userns=keep-id عند إنشاء الحاويات. يقوم الآن بإنشاء المستخدم والمجموعة. يبدو أن المشكلة الأولى مرتبطة بهذه الوظيفة نفسها لأن مجموعة المستخدمين ليس لها اسم على الرغم من وجود GUID الصحيح (لقد أبلغت عن ذلك upstream: https://github.com/containers/podman/issues/7389).

الجزء الآخر (الاضطرار إلى كتابة كلمة المرور لـ sudo) ناتج عن حقيقة أن مسار الكود المشار إليه بواسطة juanje يتم تشغيله فقط في حالة عدم وجود المستخدم الحالي في الحاوية. يعتني هذا الرمز بإنشاء المستخدم وإضافته إلى المجموعات الصحيحة وحذف كلمات المرور للمستخدم والجذر. أعتقد أن الكود الموجود في الأمر init-container يحتاج إلى إعادة هيكلة قليلاً ليتم استدعاؤه حتى مثل هذه الحالات.

يبدو أن Podman in Rawhide غير الطريق
يتعامل مع الخيار --userns = keep-id عند الإنشاء
حاويات. يقوم الآن بإنشاء المستخدم والمجموعة. ال
يبدو أن المشكلة الأولى مرتبطة بهذه الوظيفة
نفسها لأن مجموعة المستخدمين ليس لها اسم
على الرغم من وجود GUID الصحيح (لقد أبلغت أن المنبع:
حاويات / بودمان # 7389).

يبدو أنه لا يُنشئ المجموعة بالفعل. وإلا فسيكون لديك اسم. إنها مجرد إنشاء المستخدم.

أتساءل عما إذا كان يتم أيضًا إنشاء دليل رئيسي. لا اتمنى.

https://github.com/containers/podman/pull/6829 كان التغيير المسيء لـ Podman.

هذا يحدث لي الآن على Silverblue 32 باستخدام fedora- toolbox: f32 image
إصدار صندوق الأدوات: 0.0.93
إصدار podman: 2.0.5

هذا يحدث لي الآن على Silverblue 32 باستخدام fedora- toolbox: f32 image
إصدار صندوق الأدوات: 0.0.93
إصدار podman: 2.0.5

نعم ، لدي مشكلة في Silverblue 32 الآن في أي مثيل مربع أدوات جديد لـ F32. مع مثيل مربع الأدوات القديم ، لا يزال يعمل ، ولكن ليس مع الإبداعات الجديدة. لذا ، كل ما تم فعله "لإصلاحه" ، كسره على F32.

يمكن تأكيد هذه المشكلة على Fedora 32 SB مع toolbox 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
إصدار podman: 2.0.5

هذا لأن Podman 2.0.5 انزلق إلى Fedora 32.

هل من الممكن إضافة بعض الاختبارات لـ podman أو toolbox للقبض على الانحدارات مثل هذا؟ يشجع Silverblue حقًا المرء على استخدام Toolbox ، ولكي يحدث ذلك ، يجب أن يكون Toolbox موثوقًا به مثل gnome-terminal نفسها.

هل من الممكن إضافة بعض الاختبارات لـ podman أو toolbox إلى
التقاط الانحدارات مثل هذا؟ يشجع Silverblue حقًا
واحد لاستخدام Toolbox ، ولكي يحدث ذلك يحتاج Toolbox
لتكون موثوقة مثل محطة جنوم نفسها.

لقد ثبت أنها معركة شاقة بشكل مدهش لجعل فريق Podman يهتم بالتوافق مع الإصدارات السابقة أو للتحقق مما إذا كان بعض التغيير يكسر Toolbox أم لا. HarryMichal يطارد باستمرار

هل من الممكن إضافة بعض الاختبارات لـ podman أو toolbox إلى
التقاط الانحدارات مثل هذا؟ يشجع Silverblue حقًا
واحد لاستخدام Toolbox ، ولكي يحدث ذلك يحتاج Toolbox
لتكون موثوقة مثل محطة جنوم نفسها.

لقد ثبت أنها معركة شاقة بشكل مدهش لجعل فريق Podman يهتم بالتوافق مع الإصدارات السابقة أو للتحقق مما إذا كان بعض التغيير يكسر Toolbox أم لا. HarryMichal يطارد باستمرار

أعتقد أن إحدى الطرق لتجنب هذه المشكلة هي أن يكون لـ Silverblue ريبو منفصل في الدقيقة لـ podman وجميع التحديثات المنخفضة فقط التي تجتاز اختبارات الانحدار مقابل toolbox

متى من المفترض أن تصل إلى تحديثات 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. شيء مثل
صدى " مارتن: س : 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 : شكرًا لمؤشر إصدار