Baru-baru ini, seseorang membuka masalah di Podman.io:Apakah Dockerfile USER masuk akal untuk podman? Pengguna mencoba menyiapkan wadah untuk menjalankan wadah Postgresql sebagai non-root. Dia ingin membuat direktori untuk database Postgresql di direktori home-nya, dan volume mount ke dalam wadah:
$ podman run -it **-v "$PWD"/html:/output:Z** schemaspy/schemaspy:snapshot -u postgres -t pgsql11 -host 192.168.4.1 -port 5432 -db anitya
...
INFO - Starting Main v6.1.0-SNAPSHOT on 9090a61652af with PID 1 (/schemaspy-6.1.0-SNAPSHOT.jar started by java in /)
INFO - The following profiles are active: default
INFO - Started Main in 2.594 seconds (JVM running for 3.598)
INFO - Starting schema analysis
**ERROR - IOException**
**Unable to create directory /output/tables**
INFO - StackTraces have been omitted, use `-debug` when executing SchemaSpy to see them
Apakah menjalankan Podman tanpa root sebagai non-root masuk akal?
Masalah yang dia alami adalah direktori yang dia buat di direktori home, $PWD/html dimiliki oleh UID-nya. UID ini terlihat seperti root di dalam wadah, dan proses Postgresql di dalam wadah tidak berjalan sebagai root:Ini berjalan sebagai postgres pengguna (-u postgres ). Oleh karena itu, proses Postgresql tidak dapat menulis ke direktori.
Solusi mudah untuk masalah ini adalah dengan chown html direktori agar sesuai dengan UID yang dijalankan Postgresql di dalam wadah. Namun, jika pengguna mencoba untuk chown file:
chown postgres:postgres $PWD/html
chown: changing ownership of '/home/dwalsh/html': Operation not permitted
Mereka mendapat izin ditolak. Hasil ini karena pengguna tidak melakukan root pada sistem, dan tidak diizinkan untuk chown file ke UID acak:
$ grep postgres /etc/passwd
postgres:x:26:26:PostgreSQL Server:/var/lib/pgsql:/bin/bash
Jika pengguna menambahkan sudo untuk chown direktori, mereka akan mendapatkan kesalahan serupa. Sekarang direktori tersebut dimiliki oleh UID 26, tetapi UID 26 tidak dipetakan ke dalam wadah dan bukan UID yang sama dengan yang dijalankan Postgres saat berada di dalam wadah. Ingat dari artikel saya sebelumnya tentang ruang nama pengguna bahwa Podman meluncurkan wadah di dalam ruang nama pengguna, yang dipetakan dengan rentang UID yang ditentukan untuk pengguna di /etc/subuid dan /etc/subgid .
Di sistem saya, saya menjalankan dengan ruang nama pengguna ini:
$ podman unshare cat /proc/self/uid_map
0 3267 1
1 100000 65536
Hasil ini menunjukkan bahwa UID 0 dipetakan ke UID saya, 3267, sedangkan UID 1 dipetakan ke 100000, UID 2 dipetakan ke 100001, dan seterusnya. Hasil ini berarti bahwa di dalam container, UID 26 berjalan sebagai UID 100025.
Luar biasa, mari kita coba itu:
$ chown 100025:100025 $PWD/html
chown: changing ownership of '/home/dwalsh/html': Operation not permitted
Yah, itu juga tidak berhasil. Masalahnya adalah meskipun akun pengguna saya dapat menjalankan ruang nama pengguna dengan pemetaan ini, saat ini saya tidak berada di ruang nama pengguna. Saya perlu menggunakan podman unshare perintah, yang memasukkan Anda ke dalam ruang nama pengguna yang sama dengan yang digunakan Podman rootless, jadi semuanya terlihat sama persis untuk unshare seperti yang mereka lakukan untuk rootless:
$ podman unshare chown 100025:100025 $PWD/html
chown: changing ownership of '/home/dwalsh/html': Invalid argument
Error: exit status 1
Masih salah. Masalahnya sekarang adalah bahwa chown terjadi di dalam ruang nama pengguna, jadi chown perlu menggunakan UID asli, bukan UID yang dipetakan:
$ podman unshare chown 26:26 $PWD/html
Di luar ruang nama pengguna, hasil ini terlihat seperti:
$ ls -ld $PWD/html
drwxrwxr-x. 2 100025 100025 4096 Sep 13 07:14 /home/dwalsh/html
Sekarang, ketika pengguna menjalankan wadah, itu berhasil. Proses Postgresql di dalam wadah berjalan sebagai UID 26 di dalam wadah (dan 100025 di luar).
Tapi mari kita kembali ke pertanyaan awal:"Apakah menjalankan Podman tanpa root sebagai non-root masuk akal?" Jika Anda sudah menjalankan container sebagai non-root, mengapa Anda harus menjalankan Postgresql sebagai non-root yang berbeda di container Podman?
Secara default, Podman rootless berjalan sebagai root di dalam container. Kebijakan ini berarti bahwa proses dalam penampung memiliki daftar default kemampuan dengan namespace yang memungkinkan proses untuk bertindak seperti root di dalam ruang nama pengguna, termasuk mengubah UID mereka dan mengunyah file ke UID berbeda yang dipetakan ke dalam ruang nama pengguna. Jika Anda ingin menjalankan container sebagai pengguna Postgresql, Anda ingin mencegah akses ini.
Penyiapan ini juga berarti bahwa proses di dalam wadah berjalan sebagai UID pengguna. Jika proses container lolos dari container, proses tersebut akan memiliki akses penuh ke file di direktori home Anda berdasarkan pemisahan UID. SELinux masih akan memblokir akses, tetapi saya telah mendengar bahwa beberapa orang menonaktifkan SELinux . Melakukannya berarti proses yang lolos dapat membaca rahasia di direktori beranda Anda, seperti ~/.ssh dan ~/.gpg , atau informasi lain yang Anda ingin agar penampung tidak memiliki akses.
Namun, jika Anda menjalankan proses di dalam wadah sebagai UID non-root yang berbeda, maka proses tersebut akan berjalan sebagai UID tersebut. Jika mereka keluar dari wadah, mereka hanya akan memiliki akses dunia ke konten di direktori home Anda. Perhatikan bahwa untuk bekerja dengan konten di direktori ini, Anda perlu menjalankan podman unshare perintah, atau atur kepemilikan grup direktori seperti yang dimiliki oleh UID Anda (root di dalam wadah).
Dengan Podman, Anda ingin mengizinkan pengguna untuk menjalankan image container apa pun di registri container apa pun sebagai non-root jika pengguna memilihnya. Dan saya percaya bahwa menjalankan container sebagai non-root harus selalu menjadi prioritas utama Anda demi alasan keamanan.
[Ingin mencoba Red Hat Enterprise Linux? Unduh sekarang secara gratis.]