พ็อดแมน: คอนเทนเนอร์ที่ไม่มีรูท: สิทธิ์สำหรับผู้ใช้คอนเทนเนอร์

ใน จิงซ์ คอนเทนเนอร์พอดแมน จิงซ์ ผู้ใช้ใช้ในการเรียกใช้ จิงซ์ เซิร์ฟเวอร์

บนเครื่องโฮสต์ ls -alh:

drwxrwx--- 2 myuser myuser 4.0K 10 ส.ค. 22:23
drwxrwx--- 3 myuser myuser 4.0K 10 ส.ค. 22:59 ..
-rw-rw---- 1 myuser myuser 46 ส.ค. 53 22:24 น. .htpasswd

โฟลเดอร์เดียวกันภายในคอนเทนเนอร์ ls -alh:

drwxrwx--- รูท 2 รูท 4.0K 10 ส.ค. 22:23
drwxr-xr-x 1 ราก 4.0K ส.ค. 53 11:05 ..
-rw-rw---- 1 รูท 46 ส.ค. 53 22:24 .htpasswd

จิงซ์ ผู้ใช้ภายในคอนเทนเนอร์ไม่สามารถเข้าถึงได้ .htpasswd เพราะว่า o-rwx.

คำถาม: รูปแบบที่ใช้กันทั่วไปในการจัดการกรณีประเภทนี้คืออะไร ไม่มีราก คอนเทนเนอร์สากล? อาจเป็นไปได้ที่จะสร้างกลุ่ม (ใช้ภายหลังเป็นเจ้าของกลุ่มไฟล์) ซึ่งรวบรวมช่วงทั้งหมดจาก ย่อย/ย่อย สำหรับผู้ใช้โฮสต์โดยเฉพาะ - แต่จะบรรลุสิ่งนี้ได้อย่างไร

โดยใช้ตัวเลือกบรรทัดคำสั่ง --uidmap คุณสามารถระบุวิธีการ ผู้ใช้ของฉัน UID และ ผู้ใช้ของฉัน UID ย่อยจะถูกแมปลงในคอนเทนเนอร์ (ดูที่ หน้าคน สำหรับ พอดแมนวิ่ง).

ตัวเลือกบรรทัดคำสั่ง --gidmap ทำงานในลักษณะเดียวกัน แต่สำหรับ GID แทนที่จะเป็น UID

มาดู UID และ GID สำหรับผู้ใช้กัน จิงซ์ ในภาพคอนเทนเนอร์ docker.io/library/nginx

$ podman run --rm docker.io/library/nginx grep nginx /etc/passwd
nginx:x:101:101:ผู้ใช้ nginx,,,:/ไม่มีอยู่:/bin/false
$

ผลลัพธ์:

• ยูไอดี: 101
• กิด: 101

ตัวเลขนี้จะใช้ในภายหลังเมื่อตั้งค่าตัวแปรเชลล์สองตัว

$container_uid=101
$container_gid=101

(ตัวแปรเชลล์ ตู้คอนเทนเนอร์_uid และ ตู้คอนเทนเนอร์_gid ไม่มีความหมายใด ๆ นอกโพสต์นี้ เป็นเพียงการแนะนำเพื่อให้คำตอบอ่านง่ายขึ้น)

ลองดูในไฟล์ /etc/subuid และ /etc/subgid บนโฮสต์

ผู้ใช้งาน ผู้ใช้ของฉัน มี UID ย่อยและ GID ย่อยเหล่านี้

$ grep myuser /etc/subuid
myuser:231072:65536
$ grep myuser /etc/subgid
myuser:231072:65536
$ 

ผลลัพธ์:

ผู้ใช้ของฉัน มี UID ย่อย 65536 และ GID ย่อย 65536

ตัวเลขนี้จะใช้ในภายหลังเมื่อตั้งค่าตัวแปรเชลล์สองตัว

$subuid_size=65536
$subgid_size=65536

(ตัวแปรเชลล์ subuid_size และ subgid_size ไม่มีความหมายใด ๆ นอกโพสต์นี้ เป็นเพียงการแนะนำเพื่อให้คำตอบอ่านง่ายขึ้น)

แทนที่จะเงยหน้าขึ้นมอง subuid_size และ subgid_size ใน /etc/subuid และ /etc/subgidวิธีทั่วไปคือการเรียกใช้คำสั่ง

 subuid_size=$(( $( ข้อมูล podman --format "{{ range .Host.IDMappings.UIDMap }}+{{.Size }}{{end }}" ) - 1 ))
 subgid_size=$(( $( ข้อมูล podman --format "{{ range .Host.IDMappings.GIDMap }}+{{.Size }}{{end }}" ) - 1 ))

ข้อดีคือสิ่งนี้ยังใช้งานได้เมื่อไฟล์ /etc/nsswitch.conf จะใช้แทน /etc/subuid และ /etc/subgid. (ดู มนุษย์ย่อยยับ)

การสาธิต 1: แผนที่ผู้ใช้ ผู้ใช้ของฉัน บนโฮสต์ไปยังผู้ใช้ ราก ภายในคอนเทนเนอร์

ไม่จำเป็นต้องระบุ --uidmap ก็ไม่เช่นกัน --gidmap เพราะนี่คือแผนที่มาตรฐาน

สร้างไดเร็กทอรีที่เขียนได้ทั่วโลก การสาธิต1

$ mkdir สาธิต1
$ chmod 777 สาธิต 1
$

สร้างไฟล์ใหม่ ทำงานเป็น ราก ภายในคอนเทนเนอร์:

$ พ็อดแมนรัน --rm \
    -v ./demo1:/dir:Z \
      docker.io/library/nginx สัมผัส /dir/created_by_root
$

สร้างไฟล์ใหม่ ทำงานเป็น จิงซ์ ภายในคอนเทนเนอร์:

$ พ็อดแมนรัน --rm \
    --ผู้ใช้ 101:101 \
    -v ./demo1:/dir:Z \
      docker.io/library/nginx สัมผัส /dir/created_by_nginx
$

แสดงรายการไฟล์บนโฮสต์

$ ls -l สาธิต 1
รวม 0
-rw-r--r--. 1 231172 231172 0 27 ส.ค. 20:24 created_by_nginx
-rw-r--r--. 1 myuser myuser 0 ส.ค. 27 20:22 น. created_by_root
$ 

ผลลัพธ์: ไฟล์ created_by_root เป็นของ ผู้ใช้ของฉัน:ผู้ใช้ของฉัน

การสาธิต 2: แผนที่ผู้ใช้ ผู้ใช้ของฉัน บนโฮสต์ไปยังผู้ใช้ จิงซ์ ภายในคอนเทนเนอร์

สร้างไดเร็กทอรีที่เขียนได้ทั่วโลก การสาธิต2

$ mkdir สาธิต2
$ chmod 777 สาธิต 2
$

สร้างไฟล์ใหม่ ทำงานเป็น ราก ภายในคอนเทนเนอร์:

$subuid_size=65536
$subgid_size=65536
$container_uid=101
$container_gid=101
$ พ็อดแมนรัน --rm \
    --uidmap=0:1:$container_uid \
    --uidmap=$((container_uid + 1)):$((container_uid + 1)):$((subuid_size - $container_uid)) \
    --uidmap=$container_uid:0:1 \
    --gidmap=0:1:$container_gid \
    --gidmap=$((container_gid + 1)):$((container_gid + 1)):$((subgid_size - $container_gid)) \
    --gidmap=$container_gid:0:1 \
    -v ./demo2:/dir:Z \
      docker.io/library/nginx สัมผัส /dir/created_by_root
$

สร้างไฟล์ใหม่ ทำงานเป็น จิงซ์ ภายในคอนเทนเนอร์

$subuid_size=65536
$subgid_size=65536
$container_uid=101
$container_gid=101
$ พ็อดแมนรัน --rm \
    --user $container_uid:$container_gid \
    --uidmap=0:1:$container_uid \
    --uidmap=$((container_uid + 1)):$((container_uid + 1)):$((subuid_size - $container_uid)) \
    --uidmap=$container_uid:0:1 \
    --gidmap=0:1:$container_gid \
    --gidmap=$((container_gid + 1)):$((container_gid + 1)):$((subgid_size - $container_gid)) \
    --gidmap=$container_gid:0:1 \
    -v ./demo2:/dir:Z \
      docker.io/library/nginx สัมผัส /dir/created_by_nginx
$

แสดงรายการไฟล์บนโฮสต์

$ ls -l สาธิต 2
รวม 0
-rw-r--r--. 1 myuser myuser 0 ส.ค. 27 20:26 น. created_by_nginx
-rw-r--r--. 1 231072 231072 0 27 ส.ค. 20:25 created_by_root
$ 

ผลลัพธ์: ไฟล์ created_by_nginx เป็นของ ผู้ใช้ของฉัน:ผู้ใช้ของฉัน

บทสรุป

ใช้ --uidmap และ --gidmap ในลักษณะเดียวกับใน การสาธิต 2.

เคล็ดลับการแก้ปัญหา

ฉันเขียนเคล็ดลับการแก้ปัญหา: ไม่สามารถเข้าถึงอุปกรณ์หรือไฟล์ที่ส่งผ่านในคอนเทนเนอร์ที่ไม่มีรูท (ปัญหาการแมป UID/GID) ที่มีวิธีการอธิบายไว้ใน การสาธิต 2

คุณควรทราบว่าอะไรคือ UID โฮสต์เริ่มต้นสำหรับคอนเทนเนอร์ จิงซ์ UID (เพียงแตะไฟล์จากคอนเทนเนอร์โดยใช้ผู้ใช้ที่อยู่ภายใต้ จิงซ์ กำลังทำงานหรือตรวจสอบไฟล์บันทึกหรือตรวจสอบการทำงาน จิงซ์ กระบวนการ. จากนั้นใช้ สถิติ หรือ ls -ln จากผู้ใช้โฮสต์เริ่มต้น): ค่า UID ขนาดใหญ่ สมมติว่าเป็น 100030

จากนั้นคุณสามารถใช้จากผู้ใช้ที่ไม่มีสิทธิพิเศษของโฮสต์เริ่มต้น setfactl เพื่อให้สิทธิ์การเข้าถึงเพิ่มเติมแก่ผู้ใช้ 100030 ซึ่งควรเป็นดังนี้:

โฟลเดอร์ setfacl -R -m u:100030:rX,d:u:100030:rX

ถ้าคุณต้องการ จิงซ์ ผู้ใช้สามารถเขียนได้ (ซึ่งอาจไม่ใช่ความคิดที่ดี) คุณสามารถแทนที่ได้ อาร์เอ็กซ์ กับ rwX หรือทำเฉพาะในไดเร็กทอรีที่เลือกเท่านั้น การทำซ้ำเริ่มต้นด้วย ง: หมายถึง ค่าเริ่มต้น ACL ดังนั้นไดเร็กทอรีและไฟล์ที่สร้างขึ้นใหม่จึงสืบทอด ACL เพิ่มเติมเดียวกัน เมื่อตั้งค่า ACL เอาต์พุตของ ล แสดง + และหน้ากาก ACL แทนกลุ่ม ดังนั้นจึงอาจดูน่าแปลกใจ

ต่อไปนี้เป็นข้อมูลอ้างอิงต่างๆ เกี่ยวกับ ACL:

• README ของ Debian LXC (ซึ่งทำให้ฉันมีความคิด)
• รายการควบคุมการเข้าถึง POSIX บน Linux
• เอซีแอล(5)