Soluzione della community

Autorizzazioni di ZimaOS /media modificate: come gestirle in sicurezza

A beta tester found newly mounted Btrfs volumes owned by root with 755 permissions, blocking direct non-root writes at the mount root.

In sintesi: non “correggere” le radici dei mount di ZimaOS con chmod 777

Nella Beta 2 della versione 1.6.2, i volumi Btrfs appena montati apparivano come root:root con permessi 755, quindi un normale utente SSH non poteva più scrivere direttamente nella radice di /media/<volume>. Si trattava di un’osservazione reale della versione beta. Ciò non significa automaticamente che la versione attuale sia difettosa, e allentare ricorsivamente i permessi della radice dei mount è una soluzione alternativa rischiosa.

La beta ha modificato più di un percorso di sicurezza dello storage

Un rapporto correlato sulla Beta 2 di 1.6.2 mostrava che la migrazione dei dati delle app era bloccata da una nuova policy di sicurezza, e IceWhale ha riconosciuto quello specifico errore di migrazione come un problema noto da correggere. In seguito, la versione stabile 1.6.2 ha introdotto ulteriori misure di sicurezza e correzioni relative allo storage. È quindi evidente che il periodo beta comprendeva sia modifiche di sicurezza intenzionali sia almeno una regressione.

Il riepilogo delle modifiche di ZimaOS 1.6.x offre un utile contesto storico.

La documentazione pubblica attuale non promette l’accesso in scrittura non-root a ogni radice dei mount

Ora ZimaOS gestisce lo storage come un servizio amministrato utilizzato da Files, dalle condivisioni SMB e dai percorsi Docker. Il flusso di lavoro supportato consiste nel creare cartelle e condivisioni e associare le applicazioni al percorso corretto, non nel fare affidamento su scritture arbitrarie da shell nella radice di ogni disco montato.

La guida attuale allo storage di ZimaOS e la guida ai percorsi delle app e alla migrazione di ZimaOS sono riferimenti attuali più indicati rispetto alla sola modalità del filesystem della versione beta.

Se uno script necessita dell’accesso in scrittura, assegnagli una directory dedicata

sudo mkdir -p /media/YourVolume/automation
sudo chown YOUR_USER:YOUR_GROUP /media/YourVolume/automation
sudo chmod 775 /media/YourVolume/automation

Indica la directory effettivamente necessaria allo script. Non modificare ricorsivamente l’intera radice del disco. Il manuale di chmod e il manuale di chown sono i riferimenti ufficiali upstream.

Come distinguere una policy da una regressione

Se l’accesso tramite Files, SMB e app funziona, ma le scritture dirette da shell nella radice del volume non riescono, ciò può essere coerente con un modello di permessi gestito. Se l’interfaccia supportata di Migrazione dati o delle condivisioni è bloccata, raccogli l’errore esatto e la versione; si tratta di una classe di problemi diversa, che dovrebbe essere verificata sulla versione stabile attuale.