Nedávno někdo otevřel problém na Podman.io:Má Dockerfile USER smysl pro podman? Uživatel se pokoušel nastavit kontejner tak, aby spouštěl kontejner Postgresql jako jiný než root. Chtěl ve svém domovském adresáři vytvořit adresář pro databázi Postgresql a připojit jej do kontejneru:
$ 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
Má smysl provozovat rootless Podman jako non-root?
Problém, který měl, byl, že adresář, který vytvořil v domovském adresáři, $PWD/html byl ve vlastnictví jeho UID. Toto UID vypadá jako root uvnitř kontejneru a proces Postgresql uvnitř kontejneru neběží jako root:Spouští se jako postgres uživatel (-u postgres ). Proces Postgresql proto nemůže zapisovat do adresáře.
Snadným řešením tohoto problému je chown html adresář, aby odpovídal UID, se kterým Postgresql běží uvnitř kontejneru. Pokud se však uživatel pokusí soubor chown:
chown postgres:postgres $PWD/html
chown: changing ownership of '/home/dwalsh/html': Operation not permitted
Dostanou povolení odepřeno. Tento výsledek je způsoben tím, že uživatel není root v systému a nemá povoleno chown soubory náhodným UID:
$ grep postgres /etc/passwd
postgres:x:26:26:PostgreSQL Server:/var/lib/pgsql:/bin/bash
Pokud uživatel přidá sudo pro chown adresář, dostanou podobnou chybu. Nyní je adresář ve vlastnictví UID 26, ale UID 26 není namapováno do kontejneru a není to stejné UID, se kterým Postgres běží v kontejneru. Z mých předchozích článků o uživatelském jmenném prostoru si pamatuji, že Podman spouští kontejner uvnitř uživatelského jmenného prostoru, který je mapován s rozsahem UID definovaných pro uživatele v /etc/subuid a /etc/subgid .
V mém systému spouštím s tímto uživatelským jmenným prostorem:
$ podman unshare cat /proc/self/uid_map
0 3267 1
1 100000 65536
Tento výsledek ukazuje, že UID 0 je mapováno na mé UID, 3267, zatímco UID 1 je mapováno na 100 000, UID 2 je mapováno na 100 001 a tak dále. Tento výsledek znamená, že uvnitř kontejneru běží UID 26 jako UID 100025.
Výborně, zkusíme to:
$ chown 100025:100025 $PWD/html
chown: changing ownership of '/home/dwalsh/html': Operation not permitted
No, ani to nefungovalo. Problém je v tom, že i když můj uživatelský účet může spouštět uživatelský jmenný prostor s těmito mapováními, momentálně nejsem v uživatelském jmenném prostoru. Potřebuji použít podman unshare příkaz, který vás přesune do stejného uživatelského jmenného prostoru, který používá Podman bez root, takže věci vypadají úplně stejně pro unshare jako to dělají pro bezkořenové:
$ podman unshare chown 100025:100025 $PWD/html
chown: changing ownership of '/home/dwalsh/html': Invalid argument
Error: exit status 1
Stále nesprávné. Problém je nyní v tom, že chown se děje uvnitř uživatelského jmenného prostoru, takže chown potřebuje použít původní UID, nikoli namapované UID:
$ podman unshare chown 26:26 $PWD/html
Mimo uživatelský jmenný prostor tento výsledek vypadá takto:
$ ls -ld $PWD/html
drwxrwxr-x. 2 100025 100025 4096 Sep 13 07:14 /home/dwalsh/html
Nyní, když uživatel spustí kontejner, je úspěšný. Proces Postgresql uvnitř kontejneru běží jako UID 26 uvnitř kontejneru (a 100025 vně).
Ale vraťme se k původní otázce:"Má smysl provozovat rootless Podman jako non-root?" Pokud již kontejner spouštíte jako uživatel bez oprávnění root, proč byste měli spouštět Postgresql jako jiný uživatel bez oprávnění root v kontejneru Podman?
Ve výchozím nastavení běží Podman bez root v kontejneru jako root. Tato zásada znamená, že procesy v kontejneru mají výchozí seznam možností s prostorem názvů které umožňují procesům fungovat jako root uvnitř uživatelského jmenného prostoru, včetně změny jejich UID a chowningu souborů na různá UID, která jsou mapována do uživatelského jmenného prostoru. Pokud chcete kontejner spouštět jako uživatel Postgresql, chcete tomuto přístupu zabránit.
Toto nastavení také znamená, že procesy uvnitř kontejneru běží jako UID uživatele. Pokud proces kontejneru unikl kontejneru, proces by měl plný přístup k souborům ve vašem domovském adresáři na základě oddělení UID. SELinux by stále blokoval přístup, ale slyšel jsem, že někteří lidé deaktivují SELinux . Pokud tak učiníte, znamená to, že proces escape mohl číst tajné klíče ve vašem domovském adresáři, jako ~/.ssh a ~/.gpg nebo jiné informace, ke kterým nechcete, aby kontejner měl přístup.
Pokud však procesy v kontejneru spustíte jako jiné nerootové UID, pak tyto procesy poběží jako toto UID. Pokud uniknou z kontejneru, budou mít světový přístup pouze k obsahu ve vašem domovském adresáři. Pamatujte, že abyste mohli pracovat s obsahem v těchto adresářích, musíte spustit podman unshare nebo nastavte vlastnictví skupiny adresářů jako vlastnictví vašeho UID (kořen uvnitř kontejneru).
S Podmanem chcete uživatelům umožnit spouštět jakýkoli obrázek kontejneru v libovolném registru kontejneru jako uživatel bez oprávnění root, pokud se uživatel rozhodne. A věřím, že provozování kontejnerů jako non-root by mělo být z bezpečnostních důvodů vždy vaší nejvyšší prioritou.
[Chcete vyzkoušet Red Hat Enterprise Linux? Stáhněte si jej nyní zdarma.]