Comprensione della proprietà dei file utente nella finestra mobile:come evitare di modificare le autorizzazioni dei volumi collegati

Ho trovato due opzioni:

CHOWN tutte le cose (dopo aver fatto il tuo lavoro)

Ho fatto docker run -v `pwd`/shared:/shared image e il contenitore ha creato file all'interno di pwd/shared è così che è di proprietà del processo docker. Tuttavia, /shared è ancora di mia proprietà. Quindi, all'interno del processo docker, lo faccio

chown -R `stat -c "%u:%g" /shared` /shared

stat -c "%u:%g" /shared restituisce 1000:1000 nel mio caso, essendo il uid:gid del mio utente. Anche se non c'è nessun utente 1000 all'interno del contenitore docker, l'id è presente (e stat /shared dice solo "sconosciuto" se chiedi il nome utente).

Comunque, chown trasferisce obbedientemente la proprietà dei contenuti di /shared a 1000:1000 (che per quanto mi riguarda non esiste, ma fuori dal contenitore sono io). Quindi ora possiedo tutti i file. Il contenitore può ancora modificare le cose se lo desidera, perché dal suo punto di vista è root .

E tutto va bene nel mondo.

docker run -u quindi tutti i file creati avranno automaticamente il giusto proprietario

Un altro modo per farlo è il -u flag all'esecuzione della finestra mobile.

docker run -v `pwd`/shared:/shared -u `stat -c "%u:%g" /shared` ubuntu bash

In questo modo, l'utente docker all'interno del contenitore è youruid:yourgid .

Tuttavia: questo significa rinunciare alla tua autorità root all'interno del contenitore (apt-get install , eccetera.). A meno che tu non crei un utente con quel nuovo uid e lo aggiunga al root gruppo.

È corretto? Qualcuno può indicarmi la documentazione di questo, sto solo ipotizzando sulla base dell'esperimento di cui sopra.

Forse questo è solo perché entrambi hanno lo stesso valore numerico sul kernel, e se provassi su un sistema in cui il mio utente di casa non era id 1000 allora i permessi verrebbero cambiati in ogni caso?

Leggi info coreutils 'chown invocation' , che potrebbe darti un'idea migliore di come funzionano i permessi e la proprietà dei file.

Fondamentalmente, però, ogni file sulla tua macchina ha una serie di bit aggiunti che ne definiscono i permessi e la proprietà. Quando chown un file, stai solo impostando questi bit.

Quando chown un file a un particolare utente/gruppo utilizzando il nome utente o il nome del gruppo, chown cercherà in /etc/passwd per il nome utente e /etc/group affinché il gruppo tenti di associare il nome a un ID. Se il nome utente/nome del gruppo non esiste in quei file, chown fallirà.

[email protected]:/test# touch test
[email protected]:/test# ll
total 8
drwxr-xr-x  2 root root 4096 Oct 22 18:15 ./
drwxr-xr-x 22 root root 4096 Oct 22 18:15 ../
-rw-r--r--  1 root root    0 Oct 22 18:15 test
[email protected]:/test# chown test:test test
chown: invalid user: 'test:test'

Tuttavia, puoi chown un file che utilizza gli ID per quello che vuoi (entro alcuni limiti interi positivi superiori, ovviamente), indipendentemente dal fatto che esista o meno un utente/gruppo con quegli ID sulla tua macchina.

[email protected]:/test# chown 5000:5000 test
[email protected]:/test# ll
total 8
drwxr-xr-x  2 root root 4096 Oct 22 18:15 ./
drwxr-xr-x 22 root root 4096 Oct 22 18:15 ../
-rw-r--r--  1 5000 5000    0 Oct 22 18:15 test

I bit UID e GID sono impostati sul file stesso, quindi quando monti quei file all'interno del contenitore docker, il file ha lo stesso UID proprietario/gruppo che ha sull'host, ma ora è mappato su /etc/passwd nel contenitore, che probabilmente sarà un utente diverso a meno che non sia di proprietà di root (UID 0).

La vera domanda è, naturalmente, 'cosa devo fare a riguardo?' Se bob ha effettuato l'accesso come bob sulla macchina host specificata, dovrebbe essere in grado di eseguire il contenitore come bob e non avere i permessi dei file modificati sotto il suo account host. Allo stato attuale, ha effettivamente bisogno di eseguire il contenitore come finestra mobile utente per evitare che il suo account venga modificato.

Sembra che, con la tua configurazione attuale, dovrai assicurarti che i tuoi UID> nomi utente in /etc/passwd sul tuo host corrispondono ai tuoi UID> nomi utente nei tuoi contenitori /etc/passwd se vuoi interagire con la tua directory utente montata come lo stesso utente che ha effettuato l'accesso sull'host.

Puoi creare un utente con un ID utente specifico con useradd -u xxxx . Buuuut, sembra una soluzione complicata...

Potrebbe essere necessario trovare una soluzione che non monti una home directory degli utenti host.

Quindi, sono finito in questo post per cercare come ripristinare la proprietà di tutti i file (di proprietà di root) usciti da un contenitore docker eseguito come root , al mio utente non privilegiato nell'host.

Avevo bisogno che il processo all'interno del contenitore venisse eseguito come root, quindi non posso usare -u su docker run.

Non sono orgoglioso di quello che ho fatto, ma alla fine del mio script bash ho aggiunto questo:

docker run --rm -it \
    --entrypoint /bin/sh \
    -e HOST_UID=`id -u` \
    -v ${HOST_FOLDER_OWNED_BY_ROOT}:/tmp \
    alpine:latest \
    -c 'chown -R ${HOST_UID}:${HOST_UID} /tmp/'

Suddividiamo alcune righe:

• Esegui /bin/sh all'interno del contenitore:

--entrypoint /bin/sh

• Passa l'uid dell'utente corrente come variabile d'ambiente al contenitore:

-e HOST_UID=`id -u`

• Monta qualsiasi cartella di cui desideri riappropriarti per il tuo utente (piena di file di proprietà di root, emessa dal contenitore precedente eseguito come root ), sotto il /tmp di questo nuovo contenitore :

-v ${HOST_FOLDER_OWNED_BY_ROOT}:/tmp

• Esegui chown in modo ricorsivo con l'uid dell'utente host sulla directory di destinazione (montata all'interno del contenitore in /tmp ):

-c 'chown -R ${HOST_UID}:${HOST_UID} /tmp/'

Quindi, con questo, ho restituito i file di proprietà al mio attuale utente senza dover "assegnare" i privilegi a root o sudo.

È sporco, ma ha funzionato. Spero di averti aiutato.