C'è un motivo per cui esistono le autorizzazioni "proprietario"? Le autorizzazioni di gruppo non sono sufficienti?

Penso di capire piuttosto come funzionano i permessi dei file in Linux. Tuttavia, non capisco davvero perché siano divisi in tre livelli e non in due.

Vorrei rispondere ai seguenti problemi:

• Questo design intenzionale o una patch? Cioè - le autorizzazioni del proprietario / gruppo sono state progettate e create insieme ad alcune motivazioni o sono venute una dopo l'altra per rispondere a un'esigenza?
• Esiste uno scenario in cui l'utente / gruppo / altro schema è utile ma uno schema di gruppo / altro non è sufficiente?

Le risposte al primo dovrebbero citare libri di testo o forum di discussione ufficiali.

I casi d'uso che ho preso in considerazione sono:

• file privati ​​- facilmente ottenibili creando un gruppo per utente, cosa che viene spesso eseguita come in molti sistemi.
• consentendo solo al proprietario (ad esempio il servizio di sistema) di scrivere su un file, consentendo solo a un determinato gruppo di leggere e negare tutti gli altri accessi - il problema con questo esempio è che una volta che il requisito è che un gruppo abbia accesso in scrittura, l'utente / group / other non riesce. La risposta per entrambi sta usando gli ACL e non giustifica, IMHO, l'esistenza delle autorizzazioni del proprietario.

NB Ho perfezionato questa domanda dopo averla chiusa in superuser.com .

EDIT corretto "ma uno schema di gruppo / proprietario non sarà sufficiente" a "... gruppo / altro ...".

Storia

Inizialmente, Unix aveva solo le autorizzazioni per l'utente proprietario e per gli altri utenti: non c'erano gruppi. Vedi la documentazione di Unix versione 1, in particolare chmod(1). Quindi la compatibilità con le versioni precedenti, se non altro, richiede autorizzazioni per l'utente proprietario.

I gruppi vennero più tardi. Gli ACL che consentono di coinvolgere più di un gruppo nelle autorizzazioni di un file sono arrivati ​​molto più tardi.

Potenza espressiva

Avere tre autorizzazioni per un file consente autorizzazioni più precise rispetto ad avere solo due, a un costo molto basso (molto inferiore rispetto alle ACL). Ad esempio, un file può avere modalità rw-r-----: scrivibile solo dall'utente proprietario, leggibile da un gruppo.

Un altro caso d'uso sono gli eseguibili setuid che sono eseguibili solo da un gruppo. Ad esempio, un programma con modalità di rwsr-x---proprietà root:adminconsente solo agli utenti del admingruppo di eseguire quel programma come root.

"Ci sono autorizzazioni che questo schema non può esprimere" è un argomento terribile contro di esso. Il criterio applicabile è: esistono abbastanza casi espressibili comuni che giustificano il costo? In questo caso, il costo è minimo, soprattutto date le altre ragioni per l'utente / gruppo / altro trittico.

Semplicità

Avere un gruppo per utente ha un overhead di gestione piccolo ma non insignificante. È positivo che il caso estremamente comune di un file privato non dipenda da questo. Un'applicazione che crea un file privato (ad es. Un programma di consegna e-mail) sa che tutto ciò che deve fare è assegnare al file la modalità 600. Non ha bisogno di attraversare il database del gruppo cercando il gruppo che contiene solo l'utente - e cosa fare se non esiste un gruppo del genere o più di uno?

Provenendo da un'altra direzione, supponi di vedere un file e di voler controllare le sue autorizzazioni (cioè verifica che siano quelle che dovrebbero essere). È molto più facile quando puoi andare "accessibile solo all'utente, bene, dopo" rispetto a quando devi tracciare le definizioni di gruppo. (Tale complessità è la rovina dei sistemi che fanno un uso pesante di funzionalità avanzate come ACL o funzionalità.)

ortogonalità

Ogni processo esegue gli accessi al filesystem come un particolare utente e un particolare gruppo (con regole più complicate sui moderni unices, che supportano gruppi supplementari). L'utente viene utilizzato per molte cose, incluso il test per root (uid 0) e l'autorizzazione alla consegna del segnale (basata sull'utente). Esiste una naturale simmetria tra distinguere utenti e gruppi nelle autorizzazioni di processo e distinguere utenti e gruppi nelle autorizzazioni del filesystem.

Questo design intenzionale o una patch? Cioè - le autorizzazioni del proprietario / gruppo sono state progettate e create insieme ad alcune motivazioni o sono venute una dopo l'altra per rispondere a un'esigenza?

Le autorizzazioni utente / gruppo / altre su un file fanno parte del progetto Unix originale.

Esiste uno scenario in cui l'utente / gruppo / altro schema è utile ma non è sufficiente uno schema di gruppo / proprietario?

Sì, praticamente ogni scenario che potrei immaginare in cui la sicurezza e il controllo degli accessi sono importanti.

Esempio: è possibile che si desideri fornire alcuni binari / script su un sistema per eseguire solo l'accesso othere mantenere limitato l'accesso in lettura / scrittura root.

Non sono sicuro di ciò che hai in mente per un modello di autorizzazione del file system che ha solo autorizzazioni proprietario / gruppo. Non so come si possa avere un sistema operativo sicuro senza l'esistenza di una othercategoria.

EDIT: Supponendo che tu intendessi qui le group/otherautorizzazioni sono tutto ciò che sarebbe necessario, quindi suggerisco di escogitare un modo per gestire le chiavi crittografiche o un modo in cui solo gli utenti giusti possano accedere al loro spool di posta. Ci sono casi in cui una chiave privata potrebbe aver bisogno di una user:userproprietà rigorosa , ma altri casi in cui ha senso assegnarla user:group.

file privati ​​- facilmente ottenibili creando un gruppo per utente, cosa che viene spesso eseguita come in molti sistemi.

È scontato che ciò sia facile, ma è altrettanto facile con l'esistenza di un othergruppo ...

consentendo solo al proprietario (ad esempio il servizio di sistema) di scrivere su un file, consentendo solo a un determinato gruppo di leggere e negare tutti gli altri accessi - il problema con questo esempio è che una volta che il requisito è che un gruppo abbia accesso in scrittura, l'utente / group / other non riesce. La risposta per entrambi sta usando gli ACL e non giustifica, IMHO, l'esistenza delle autorizzazioni del proprietario.

Ho evidenziato la parte della tua affermazione che sembra reiterare il mio punto sulla necessità logica di una othercategoria nelle autorizzazioni del file system Unix.

Un tale progetto di file system che sembra contemplare (da quello che posso dire) sarebbe insicuro o ingombrante. Unix è stato progettato da alcune persone molto intelligenti e penso che il loro modello offra il miglior equilibrio possibile tra sicurezza e flessibilità.

Questo design intenzionale o una patch? Cioè - le autorizzazioni del proprietario / gruppo sono state progettate e create insieme ad alcune motivazioni o sono venute una dopo l'altra per rispondere a un'esigenza?

Sì, questo è un progetto deliberato che è stato presente in UNIX sin dai primi giorni. È stato implementato su sistemi in cui la memoria veniva misurata in KB e le CPU erano estremamente lente per gli standard odierni. Le dimensioni e la velocità di tali ricerche erano importanti. Gli ACL avrebbero richiesto più spazio e sarebbero stati più lenti. Funzionalmente, il everyonegruppo è rappresentato dagli altri flag di sicurezza.

Esiste uno scenario in cui l'utente / gruppo / altro schema è utile ma non è sufficiente uno schema di gruppo / proprietario?

Le autorizzazioni che utilizzo comunemente per l'accesso ai file sono: (Sto usando i valori di bit per semplicità e perché è così che li imposto di solito.)

• 600oppure 400: Accesso solo utente (e sì, concedo l'accesso in sola lettura all'utente).
• 640oppure 660: accesso utente e gruppo.
• 644, 666Oppure 664: l'utente, gruppo, e altri accessi. Qualsiasi schema di autorizzazione a due livelli può gestire solo due di questi tre casi. Il terzo richiederebbe ACL.

Per directory e programmi che uso comunemente:

• 700oppure 500: accesso solo dell'utente
• 750oppure 710: accesso solo al gruppo
• 755, 777, 775, O 751: l'utente, gruppo, e altri accessi. Gli stessi commenti valgono per i file.

Quanto sopra è il più comunemente usato, ma non un elenco esaustivo delle impostazioni di autorizzazione che uso. Le autorizzazioni di cui sopra combinate con un gruppo (a volte con un bit di gruppo appiccicoso nelle directory) sono state sufficienti in tutti i casi in cui avrei potuto usare un ACL.

Come è stato notato sopra, è molto facile elencare l'autorizzazione in un elenco di directory. Se gli ACL non vengono utilizzati, posso controllare le autorizzazioni di accesso solo con un elenco di directory. Quando lavoro con sistemi basati su ACL, trovo molto difficile verificare o controllare le autorizzazioni.

Il sistema di autorizzazione utente / gruppo / altro è stato progettato prima dell'invenzione degli ACL. Risale ai primi giorni di UNIX, quindi non si può dire che il problema dovrebbe essere risolto con ACL. Anche se il concetto di ACL sembra ovvio, avrebbe comportato una quantità significativa [per il giorno] di sovraccarico aggiuntivo per archiviare e gestire una quantità variabile di informazioni di autorizzazione con ciascun file, piuttosto che un importo fisso.

L'uso di ACL per ogni cosa significa anche che non hai un sottoinsieme ben definito delle informazioni di autorizzazione che possono essere mostrate "a colpo d'occhio". L'output per ls -lmostra le autorizzazioni standard (utente / gruppo / altro), il nome dell'utente e del gruppo e una notazione aggiuntiva (ad es. +O @segno) sulle voci a cui è associato un ACL, il tutto in una riga. Il tuo sistema richiederebbe di identificare i "primi due" gruppi nell'ACL per fornire funzionalità equivalenti.

Come ulteriore punto, un file deve ancora avere un proprietario nel modello UNIX perché gli ACL UNIX non prevedono chi è autorizzato a modificare l'ACL.