Docker en het host filesystem owner matching probleem 

Containers blijven niet langer beperkt tot servers. Je ziet ze steeds vaker op desktops verschijnen: als CLI-apps of als ontwikkelomgevingen. Dit wordt het "container-als-OS-app" gebruik genoemd. 

Wat is het "container-als-OS-app" gebruiksscenario? 

Een "OS-app" is simpelweg een app die: 

• Draait op jouw machine (dus niet in de browser of op een server). 
• Bestanden leest of schrijft van/naar het hostbesturingssysteem. Bestanden die later mogelijk worden bekeken of aangepast door andere (niet-Docker) apps, zoals je favoriete tekstverwerker. 

Een OS-app hoeft niet per se grafisch te zijn. Sterker nog, de meeste OS-apps die gecontaineriseerd worden, zijn command-line tools. Denk aan: 

• bash
• ls
• Git
• De C/Go/Rust compiler
• Je tekstverwerker 

Docker wordt steeds vaker gebruikt om zulke apps te verpakken. Enkele voorbeelden: 

• rust-musl-builder — een handige compilatieomgeving voor Rust waarmee je statisch gelinkte binaries kunt maken.
• Holy Build Box — een slimme compilatieomgeving voor C/C++ die draagbare Linux-binaries genereert die op elke Linux-distributie werken.

Beide voorbeelden lezen of schrijven bestanden van/naar jouw hostbesturingssysteem.

Misschien verrassend, maar veel ontwikkelomgevingen vallen ook in deze categorie. Stel je voor dat je een ontwikkelomgeving opzet voor je Ruby-, Node.js- of Go-app met Docker-Compose. Zo'n Docker-Compose-omgeving doet vaak het volgende: 

1. Het koppelt je projectmap (op jouw systeem) aan de container.
2. (Voor gecompileerde talen:) Binnen de container wordt de broncode gecompileerd. De resultaten en cachebestanden worden in je projectmap opgeslagen.
3. In de container start de app en draait totdat jij besluit om te stoppen.
4. (Voor frameworks waar dit relevant is:) Als je broncode op de host verandert, herlaadt de app in de container automatisch de nieuwe code.
5. De app in de container schrijft logbestanden naar je projectmap. 

De belangrijkste conclusie: ontwikkelomgevingen lezen en schrijven voortdurend bestanden van/naar jouw systeem. Bestanden die jij later ook wilt kunnen bewerken met andere apps. 

Voorbeeld: op een Linux-machine (niet op macOS; daarover later meer), laten we een root-container een bestand laten aanmaken: 

docker run --rm -v "$(pwd):/host" busybox touch /host/foo.txt
 

Dit bestand is nu van root, en jij kunt er niets mee: t:

$ ls -l foo.txt
-rw-r--r-- 1 root root 0 Jan 17 10:36 foo.txt
$ echo hi > foo.txt
-bash: foo.txt: Permission denied

Sommige containers volgen betere beveiligingspraktijken en draaien als normale gebruiker. Maar dat creëert weer een nieuw probleem: ze kunnen helemaal niet meer schrijven naar jouw systeem! Waarom? Omdat jouw map alleen beschrijfbaar is voor jou als eigenaar, niet voor een willekeurige gebruiker in de container.

Hier is een voorbeeld van een container die als normale gebruiker draait in plaats van root: 

FROM debian:10

RUN addgroup --gid 1234 app && \
   adduser --uid 1234 --gid 1234 --gecos "" --disabled-password app
USER app
 

We bouwen en draaien dit, en proberen een bestand aan te maken: 

$ docker build . -t usercontainer
$ docker run --rm -v "$(pwd):/host" usercontainer touch /host/foo.txt
touch: cannot touch `/host/foo.txt': Permission denied
 

Oplossingsstrategieën

Er zijn twee hoofdstrategieën om dit probleem aan te pakken: 

1. De UID/GID van de container matchen met die van jouw systeem.
2. Het pad van de host opnieuw koppelen in de container met behulp van BindFS. 

Elke strategie heeft zijn eigen uitdagingen. Laten we eens kijken hoe ze werken en wat de voor- en nadelen zijn. 

Voorbeeld: een container account maken met dezelfde UID/GID als de host account

Dit voorbeeld laat zien hoe UID's en GID's werken. Je moet dit op Linux uitvoeren (macOS-gebruikers hebben dit probleem immers niet). Laten we eerst checken wat jouw UID/GID is: 

hongli@host$ id
uid=1000(hongli) gid=1000(hongli) groups=1000(hongli),27(sudo),999(docker)
 

Mijn UID en GID zijn beide 1000. 

Nu starten we een interactieve Debian-container. We koppelen de huidige werkdirectory van de host aan de container, onder /host.

docker run -ti --rm -v "$(pwd):/host" debian:10

In de Debian container’s root shell, maken we:

• Een groep genaamd matchinguser, met GID 1000.
• Een gebruiker matchinguser met UID 1000. We hebben geen wachtwoord nodig voor dit voorbeeld. 

addgroup --gid 1000 matchinguser
adduser --uid 1000 --gid 1000 --gecos "" --disabled-password matchinguser

Nu gebruiken we dit account om een bestand aan te maken in de directory: 

apt update
apt install -y sudo
sudo -u matchinguser -H touch /host/foo2.txt

Als we de bestandsrechten van /host/foo2.txt vanuit de container bekijken, dan zien we dat deze eigendom is van matchinguser:

root@container:/# ls -l /host/foo2.txt
-rw-r--r-- 1 hostuser hostuser 0 Mar 15 09:45 /host/foo2.txt

Maar als we hetzelfde bestand vanaf de host bekijken, dan zien we dat het eigendom is van de hostgebruiker:

hongli@host:/# ls -l foo2.txt
-rw-r--r-- 1 hongli hongli 0 Mar 15 09:45 /host/foo2.txt
 

Dit komt omdat het bestand UID en GID 1000 heeft, wat in de container overeenkomt met matchinguser, maar op de host overeenkomt met hongli.

Het bovenstaande entrypoint-script is een goede poging, maar houdt geen rekening met deze belangrijke kanttekeningen:

1. Wat als er al een andere container-gebruiker/groep bestaat met dezelfde UID/GID als de host-UID/GID?
Dan is het niet mogelijk om een nieuw gebruikersaccount/groep aan te maken met de host-UID/GID.

Je kunt dit oplossen door de conflicterende container-gebruiker/groep te verwijderen. Maar afhankelijk van welk account precies wordt verwijderd (en waarvoor dat account binnen de container wordt gebruikt), kan dit het gedrag van de container op onvoorspelbare manieren verslechteren.

Als vuistregel worden accounts met UID < 1000 en groepen met GID < 1000 beschouwd als systeemaccounts en -groepen. Deze worden beheerd door de OS-onderhouders en gebruikers zouden hier niet mee moeten knoeien.

Daarentegen zijn accounts/groepen met UID/GID >= 1000 "normale accounts"/"normale groepen" die niet door OS-onderhouders worden beheerd. Gebruikers van het OS kunnen met deze accounts doen wat ze willen. Maar hier moet je je afvragen: wie zijn in deze context "gebruikers van het OS"? Als dat alleen jijzelf bent en je volledige controle hebt over welke normale accounts in je container komen, dan is er geen probleem. Maar als je een basisimage gebruikt dat door iemand anders is geleverd, en dat image komt al met vooraf aangemaakte normale accounts, dan moet je jezelf afvragen of het veilig is om deze te wijzigen.

2. Wat als de hostgebruiker root is?
De hostgebruiker als root (met UID 0) is een speciaal geval waarmee je rekening moet houden. Het is geen goed idee om het bestaande root-account in de container te verwijderen en door een ander account te vervangen. Dus als het entrypoint-script detecteert dat de host-UID 0 is, dan zou het de volgende opdracht als root moeten uitvoeren.

Maar op vreemde systemen zou de root-gebruiker van de host een niet-nul-GID kunnen hebben! Dus als het entrypoint-script detecteert dat de UID 0 is maar de GID niet-nul, dan moet het de GID van de rootgroep wijzigen. Dit kan weer leiden tot het probleem beschreven in (1): wat als er al een andere groep is met dezelfde GID?

3. In het geval van vooraf aangemaakte accounts: wat met de bestanden die het bezit?
Als je container gebruik maakt van een vooraf aangemaakt account, dan moet je je na het wijzigen van de UID en GID van dat account afvragen wat je moet doen met bestanden die eigendom waren van dat account. Moet de UID/GID van deze bestanden worden bijgewerkt naar de nieuwe UID/GID?

De Debian-versie van usermod --uid werkt automatisch de UID's bij van alle bestanden in de home directory van dat account (recursief). Groupmod werkt echter de GID's niet bij, dus je moet dat zelf doen vanuit je entrypoint-script.
usermod --uid werkt de UID's van bestanden buiten de home directory van dat account niet bij. Het is aan jouw entrypoint-script om deze bestanden bij te werken, indien aanwezig.

Verder moet je je afvragen of het een goed idee is om de UID's van deze bestanden bij te werken. Als deze bestanden voor iedereen leesbaar zijn en je container ze nooit schrijft, dan is het bijwerken van hun UID's/GID's overbodig. Als er veel bestanden zijn, kan het bijwerken van hun UID's/GID's aanzienlijk veel tijd kosten. Ik liep tegen dit probleem aan bij het gebruiken van rust-musl-builder. Rust was geïnstalleerd via rustup in de home directory, en het updaten van UIDs/GIDs van ~/.rustup kost veel tijd. 

Misschien is het alleen nodig om de UID's/GID's van specifieke bestanden bij te werken. Bijvoorbeeld, alleen de bestanden direct in de thuismap, niet recursief. Dit moet per container worden beoordeeld.
Tot slot hebben sommige Linux-kernelversies bugs in OverlayFS. Het bijwerken van de UID's/GID's van bestaande bestanden werkt niet altijd. Dit kan worden omzeild door een kopie te maken van die bestanden, de originele bestanden te verwijderen en de kopieën te hernoemen naar hun oorspronkelijke namen.

4. Vereist root-rechten
Het eenvoudige voorbeeld-entrypoint-script is verantwoordelijk voor het aanmaken en wijzigen van accounts, wat root-rechten vereist. Het is ook verantwoordelijk voor het verlagen van rechten naar een normaal account. Dit betekent echter dat we de USER-stanza in de Dockerfile niet kunnen gebruiken. Bovendien kunnen gebruikers de container niet uitvoeren met de --user vlag, wat contra-intuïtief is en sommige gebruikers bezorgd kan maken over de beveiliging van de container.
Een oplossing is om van het entrypoint-programma een setuid root executable te maken. Dit betekent dat je de "setuid filesystem bit" aanzet op het entrypoint-programma, zodat het programma root-rechten krijgt wanneer het wordt uitgevoerd, zelfs als het programma door een niet-root gebruiker werd gestart.

De setuid-bit wordt slechts door enkele specifieke programma's gebruikt die betrokken zijn bij privilege-escalatie. Sudo gebruikt bijvoorbeeld de setuid-bit. Zoals je je kunt voorstellen, is de setuid-bit zeer gevaarlijk. Bij onzorgvuldig gebruik kan iedereen root-rechten krijgen zonder authenticatie. Een setuid root-programma moet specifiek geschreven zijn om misbruik onmogelijk te maken.

Een andere complicatie is dat de setuid root-bit niet werkt op shell-scripts, alleen op "echte" uitvoerbare bestanden! Als je gebruik wilt maken van deze bit, moet je het entrypoint-programma schrijven in een taal die naar native uitvoerbare bestanden compileert, zoals C, C++, Rust of Go.

Onder welke voorwaarden is het veilig om een setuid root entrypoint-programma uit te voeren? Eén antwoord is: als het entrypoint's PID 1 is. Dit betekent dat het het allereerste programma is dat in de container wordt uitgevoerd. Dit geeft aan dat het entrypoint-programma direct door docker run wordt uitgevoerd, dus we kunnen aannemen dat het een redelijk veilige omgeving is.

Maar het controleren op PID 1 werkt niet in combinatie met docker run --init, dat een init-proces opstart (dat als taak heeft om het PID 1 zombie reaping problem op te lossen). Het init-proces kan willekeurig werk uitvoeren en willekeurige processen uitvoeren voordat het ons entrypoint-programma uitvoert. We kunnen dus ook niet aannemen dat onze PID 2 is. In plaats daarvan kunnen we controleren of we een kindproces zijn van het init-proces. Want nadat het init-proces de volgende opdracht uitvoert, zal het geen verdere opdrachten meer uitvoeren.

5. Vereist extra omgevingsvariabelen
In de ideale wereld willen we dat gebruikers onze container kunnen uitvoeren met docker run --user HOST_UID, en dat het entrypoint van de container automatisch begrijpt dat de waarden die aan --user worden doorgegeven de host-UID/GID zijn.
 

Maar ons voorbeeld-entrypoint-script vereist dat de gebruiker die informatie via omgevingsvariabelen specificeert. Gebruikers moeten dus redundante parameters doorgeven, zoals dit:

docker run \
 -e HOST_UID="$(id -u)" \
 -e HOST_GID="$(id -g)" \
 --user "$(id -u):$(id -g)" \
 ...

Dit is geen goede gebruikerservaring.

Met de bovenstaande kanttekeningen wordt het entrypoint-script niet langer triviaal. Als je kanttekening 4 wilt oplossen, kan het entrypoint niet eens meer een shell-script zijn.

Conclusie

Er zijn twee belangrijke strategieën om het probleem van het matchen van de eigenaar van het host-bestandssysteem op te lossen:

• Het matchen van de UID/GID van de container met de UID/GID van de host.
  Het opnieuw mounten van het host-pad in de container met behulp van BindFS.

Beide strategieën hebben hun eigen voordelen en nadelen:

• BindFS gebruiken is gemakkelijk zelf te implementeren, maar vereist dat de container wordt gestart met root-rechten en in geprivilegieerde modus.
  De container uitvoeren met een overeenkomende UID/GID vereist geen geprivilegieerde modus. Het maakt ook mogelijk dat de container zonder root-rechten draait. Maar het is moeilijk te implementeren als je alle kanttekeningen wilt aanpakken.

De kanttekeningen van BindFS kunnen niet worden opgelost. Maar de kanttekeningen met betrekking tot "het matchen van de container-UID/GID met die van de host" kunnen worden opgelost, ook al vereist dat behoorlijk wat engineering.
Gewapend met de kennis uit dit artikel kun je zelf een oplossing bouwen. Maar zou het niet mooi zijn als je een oplossing kunt gebruiken die al door iemand anders is gemaakt — vooral als die oplossing strategie 1 gebruikt, die moeilijk te implementeren is? Blijf kijken voor het volgende artikel, waarin we zo'n oplossing zullen introduceren!

Oorspronkelijk gepubliceerd op Joyful Bikeshedding.

Het Docker-pictogram dat in de illustraties van dit artikel wordt gebruikt, is gemaakt door  Flatart.