Lista di controllo per la mappatura di utenti e gruppi dei container per le condivisioni NAS

Eva Wong

IceWhale author

Eva Wong è la Technical Writer e smanettatrice residente di ZimaSpace. Una geek da sempre con una passione per homelab e software open-source, si specializza nel tradurre concetti tecnici complessi in guide accessibili e pratiche. Eva crede che l'auto-ospitare debba essere divertente, non intimidatorio. Attraverso i suoi tutorial, dà potere alla comunità di demistificare le configurazioni hardware, dalla costruzione del loro primo NAS al dominio dei container Docker.

Container User and Group Mapping Checklist for NAS Shares - Zima Store Online

L’approccio più sicuro consiste nel trattare la verifica della mappatura delle identità numeriche, dall’esportazione NAS fino al mount sull’host e al processo del container in esecuzione, come una sequenza di controlli osservabili, non come un singolo comando.

Su un host Linux per container che utilizza condivisioni NAS basate su SMB o NFS, il rischio concreto è che un container riesca a vedere un percorso montato dal NAS, ma che le operazioni di lettura o scrittura falliscano con errori di autorizzazione. Registra l’identità corrente e il punto di ripristino, inizia dal discriminatore meno invasivo, interpreta i risultati positivi e negativi prima di modificare un’altra variabile e fermati quando lo storage diventa instabile o l’unica copia recuperabile verrebbe esposta. Il flusso di lavoro seguente termina solo quando il carico di lavoro originale funziona oppure quando le evidenze raggiungono una soglia di escalation.

Identifica l’identità effettiva del processo del container

Esamina la documentazione dell’immagine, l’impostazione user di Compose, le variabili d’ambiente, il comportamento dell’entrypoint e gli UID, GID e gruppi supplementari del processo applicativo in esecuzione. Le variabili denominate PUID e PGID sono convenzioni delle immagini, non funzionalità Docker universali; verifica quindi che questa immagine le supporti.

Un caso della community LinuxServer relativo a un caso di autorizzazioni del container con PUID e PGID dimostra che valori PUID e PGID apparentemente corretti possono comunque lasciare inaccessibile un bind mount. Usa il caso come promemoria per ispezionare il processo e il mount in esecuzione, non come prova che ogni immagine implementi la stessa logica di inizializzazione.

Registra i valori numerici con id all’interno del container e sull’host. Fermati se l’applicazione viene eseguita come root solo perché in precedenza si sono verificati problemi di autorizzazione; l’accesso root nasconde il difetto di mappatura e aumenta l’impatto di un servizio compromesso.

Traccia la proprietà dal NAS al mount sull’host

Sul NAS, esamina il proprietario numerico, il gruppo, i permessi, l’ACL e l’ACL predefinito della directory di destinazione. Sull’host del container, esamina gli stessi oggetti montati e confronta i valori numerici. Se i nomi differiscono ma i numeri coincidono, le etichette sono solo estetiche; se i numeri differiscono, il percorso di autorizzazione è realmente diverso.

Per NFS, includi le opzioni di esportazione, la versione NFS, la mappatura degli ID, il root squashing e l’identità del mount del client. Per SMB, includi le credenziali di mount, l’identità mappata lato server, le opzioni di presentazione uid o gid e l’eventuale uso delle estensioni Unix o della traduzione ACL.

Non modificare contemporaneamente gli ACL del server e le opzioni di mount del client. La fase è superata quando un file di test presenta un proprietario numerico noto e l’host rileva una mappatura stabile dopo lo smontaggio, il rimontaggio e il riavvio.

Verifica il bind mount e i gruppi supplementari

Conferma che il percorso sorgente del container sia il mount dell’host previsto, anziché una directory locale vuota creata prima del montaggio della condivisione di rete. Ispeziona il mount di runtime, quindi verifica l’elenco, la lettura, la creazione, la ridenominazione e l’eliminazione come utente dell’applicazione in una sottodirectory usa e getta.

Un caso di Server Fault documenta un’incongruenza nelle autorizzazioni ACL NFS anche quando il proprietario e le voci ACL sembrano allineati, illustrando perché sia necessario esaminare la maschera ACL, la mappatura del server e l’identità effettiva. Acquisisci getfacl sia sulla directory sia sul file creato.

Se è previsto l’accesso tramite gruppo, aggiungi il gruppo numerico supplementare supportato e ricrea il container, perché i gruppi del processo vengono fissati all’avvio. Usa la guida ZimaSpace su diagnosi dei percorsi vuoti nel container quando l’applicazione si avvia su un percorso vuoto; si tratta di un problema di ordine dei mount, non di un problema ACL.

-15% OFF

ZimaBoard 2 - Mini server domestico per la tua grande idea

Single board computer zimaboard2

Applica la correzione dell’identità più circoscritta e ripeti il test

Preferisci allineare l’UID, il GID o il gruppo supplementare supportato dall’applicazione con i criteri del NAS. Usa un gruppo condiviso e un ACL ereditato quando più servizi collaborano. Evita permessi scrivibili da chiunque, modifiche ricorsive della proprietà su dataset non correlati e container privilegiati come scorciatoie.

Ricrea il container, rimonta la condivisione se sono cambiate le opzioni di mappatura e ripeti le stesse operazioni. Riavvia una volta l’host per verificare che l’ordine dei mount e l’identità numerica persistano dopo l’avvio. Conferma che i file appena creati restino scrivibili dagli utenti umani previsti senza concedere al container diritti non necessari.

Chiudi la checklist quando l’app supera il carico di lavoro originale, le operazioni negate continuano a essere negate e la proprietà resta stabile dopo il riavvio. Esegui l’escalation se gli user namespace, le mappature rootless o i servizi di identità del NAS riscrivono gli ID in un modo non supportato dall’immagine scelta.