Lati negativi di umask 077?

Quali sono i contro, per avere un umask restrittivo di 077? Molte distro (credo tutte, tranne Red Hat?) Hanno un umask predefinito di 022, configurato in / etc / profile. Questo sembra troppo insicuro per un sistema non desktop, a cui accedono più utenti, e la sicurezza è preoccupante.

Su una nota correlata, su Ubuntu, anche le home directory degli utenti sono create con 755 autorizzazioni e il programma di installazione afferma che ciò serve a facilitare la condivisione dei file da parte degli utenti. Supponendo che gli utenti siano a proprio agio nell'impostare manualmente le autorizzazioni per rendere condivisi i file, questo non è un problema.

Quali altri aspetti negativi ci sono?

022 rende le cose convenienti. 077 rende le cose meno convenienti, ma a seconda delle circostanze e del profilo d'uso, potrebbe non essere meno conveniente del doverle utilizzare sudo.

Direi che, come sudo, il beneficio di sicurezza reale e misurabile che ottieni da questo è trascurabile rispetto al livello di dolore che infliggi a te stesso e ai tuoi utenti. Come consulente, sono stato disprezzato per le mie opinioni sudoe sfidato a rompere numerose sudoconfigurazioni, e devo ancora impiegare più di 15 secondi per farlo. La tua chiamata.

Conoscere umaskè buono, ma è solo un singolo corn flake nella "colazione completa". Forse dovresti chiederti "Prima di andare a fare confusione con le configurazioni predefinite, la cui coerenza dovrà essere mantenuta attraverso le installazioni e che dovrà essere documentata e giustificata per le persone che non sono scarse, cosa comprerà me?"

Umask è anche un built-in bash che può essere impostato dai singoli utenti nei loro file di inizializzazione della shell ( ~/.bash*), quindi non si è davvero in grado di imporre facilmente il file umask. È solo un valore predefinito. In altre parole, non ti sta comprando molto.

L'aspetto negativo più ovvio è quando inizi a creare file / directory in una directory condivisa, aspettandoti che altri utenti possano accedervi.

Naturalmente, è solo una questione di non dimenticare di impostare l'umask corretta prima di fare cose che devono essere condivise da tutti gli utenti.

Un altro avvertimento (non proprio un aspetto negativo, una volta che ne sei consapevole) è quando inizi a fare cose sudo come l'installazione di programmi locali, gemme ruby, uova di pitone (ovviamente il sistema operativo non gestisce i pacchetti), la creazione di file di configurazione e così via.

Ti metterai nei guai perché umask è ereditato dalla sessione sudo, quindi solo root sarà in grado di accedere ai file / directory che crei. sudo può essere configurato per impostare automaticamente umask nel modo desiderato: questa domanda è trattata su superuser.com .

Umask non sarebbe appropriato se stai cercando di controllare ciò che gli altri utenti possono vedere gli uni dagli altri. Tuttavia, se si dispone e si lavora con numerosi file sensibili al punto che chiedere l'autorizzazione per accedervi è meno fastidioso / rischioso che consentire alle persone di vedere tutto ciò che vogliono, di una umask di 077 sarebbe una buona idea.

Ho alcuni file sensibili su un file server che gestisco. Penso che impostare una umask restrittiva e avere uno script periodico, forse un lavoro cron per impostare autorizzazioni più specifiche per gli elementi in determinate cartelle sarebbe la soluzione ideale per me. Quando lo avvierò, posterò di nuovo qui e ti farò sapere come ha funzionato.

@ [I ragazzi bashing sudo] Inizia una nuova discussione per questo, potrebbero essere necessari diversi thread propri e questo thread riguarda umask.

Le applicazioni di terze parti che utilizzano i propri sistemi di installazione possono avere presupposti integrati sull'umask predefinito del sistema.

Come esempio pratico, dopo aver aggiornato un database Oracle 10 su un sistema con umask impostato su 077, le applicazioni sullo stesso sistema non sono riuscite ad accedere al database ... perché le librerie essenziali per i client del database e le directory delle librerie si trovavano in, erano ora protetti in modo che solo l' oracleutente potesse accedervi, il che ovviamente non era come avrebbero dovuto funzionare le cose.

Si scopre che il processo di aggiornamento di Oracle non si è preoccupato specificamente che le autorizzazioni delle librerie client consentissero ad altri utenti di usarle, ma si è invece affidato al presupposto che i file aggiunti dal programma di aggiornamento sarebbero stati creati con umask 022 e quindi utilizzabili per impostazione predefinita. Dopo alcuni giudiziosichmod -R a+rX comandi per le directory appropriate, tutto andò di nuovo bene.

Certo, questo avrebbe potuto essere evitato trattando l' oracleaccount come un account di sistema speciale con umask standard 022 e limitando l'umask 077 solo agli account utente effettivamente in grado di accedere ... ma penso che questo sia un buon esempio di come "indurire" la coperta "le decisioni possono avere effetti collaterali imprevisti.

.rpme i .debpacchetti contengono informazioni esplicite sui permessi per tutti i file che contengono, quindi generalmente non hanno il rischio di errori di questo tipo.

Ho questa linea nel mio ~/.zshrc

umask 0077

impostarlo a livello globale non è probabilmente una buona idea, ma impostarlo come predefinito nel file rc probabilmente non danneggerà o addirittura impostarlo come predefinito nel /etc/skel/.rcfile. a livello di sistema causerà comunque problemi.

Causerà problemi su un server; ad esempio, quando più applicazioni sono in esecuzione come utenti diversi nel tentativo di accedere ai file da utenti diversi. Come apache che legge i file di configurazione o che legge pi-hole dnsmasq.conf. Basta eseguirlo su utenti che potrebbero beneficiarne come singole home directory, non esplicitamente impostate /etc/profile.