Cronologia
Originariamente, Unix aveva solo i permessi 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 le autorizzazioni per l'utente proprietario.
I gruppi sono arrivati dopo. Gli ACL che consentono di coinvolgere più di un gruppo nei permessi di un file sono arrivati molto più tardi.
Potere espressivo
Avere tre autorizzazioni per un file consente autorizzazioni più granulari rispetto ad averne solo due, a un costo molto basso (molto inferiore rispetto agli ACL). Ad esempio, un file può avere la modalità rw-r----- :scrivibile solo dall'utente proprietario, leggibile da un gruppo.
Un altro caso d'uso sono gli eseguibili setuid eseguibili solo da un gruppo. Ad esempio, un programma con modalità rwsr-x--- di proprietà di root:admin consente solo agli utenti nel admin group per eseguire quel programma come root.
"Ci sono permessi che questo schema non può esprimere" è un terribile argomento contro di esso. Il criterio applicabile è:ci sono abbastanza casi esprimibili comuni che giustificano il costo? In questo caso, il costo è minimo, soprattutto considerando gli altri motivi del trittico utente/gruppo/altro.
Semplicità
Avere un gruppo per utente ha un piccolo ma non trascurabile sovraccarico di gestione. È bene che il caso estremamente comune di un file privato non dipenda da questo. Un'applicazione che crea un file privato (ad esempio un programma di consegna di posta elettronica) sa che tutto ciò che deve fare è assegnare al file la modalità 600. Non ha bisogno di attraversare il database del gruppo alla ricerca del gruppo che contiene solo l'utente - e cosa fare se non esiste un gruppo di questo tipo o ce ne sono più di uno?
Venendo da un'altra direzione, supponiamo di vedere un file e di voler controllare i suoi permessi (cioè controllare che siano come dovrebbero essere). È molto più semplice quando puoi passare a "accessibile solo all'utente, va bene, il prossimo" rispetto a quando devi tracciare le definizioni di gruppo. (Tale complessità è la rovina dei sistemi che fanno un uso massiccio 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 sugli unice moderni, 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 la distinzione di utenti e gruppi nei permessi dei processi e la distinzione di utenti e gruppi nei permessi del filesystem.
È questo design deliberato o una patch? Ovvero:i permessi del proprietario/gruppo sono stati progettati e creati insieme con qualche logica o sono venuti uno dopo l'altro per rispondere a un'esigenza?
I permessi utente/gruppo/altri su un file fanno parte del design Unix originale.
C'è uno scenario in cui lo schema utente/gruppo/altro è utile ma uno schema gruppo/proprietario non sarà sufficiente?
Sì, praticamente ogni scenario che potrei immaginare in cui la sicurezza e il controllo degli accessi sono importanti.
Esempio:potresti voler dare ad alcuni binari/script su un sistema l'accesso di sola esecuzione a other e mantieni l'accesso in lettura/scrittura limitato a root .
Non sono sicuro di cosa hai in mente per un modello di autorizzazione del file system che ha solo autorizzazioni di proprietario/gruppo. Non so come si possa avere un sistema operativo sicuro senza l'esistenza di un other categoria.
MODIFICA: Supponendo che tu intendessi qui group/other le autorizzazioni 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 possono accedere al proprio spool di posta. Ci sono casi in cui una chiave privata potrebbe richiedere rigorosamente user:user proprietà ma altri casi in cui ha senso assegnarlo user:group proprietà.
file privati - ottenibili molto facilmente creando un gruppo per utente, qualcosa che viene spesso fatto come in molti sistemi.
Premesso che questo è facile da fare, ma è altrettanto facile con l'esistenza di un other gruppo...
consentire solo al proprietario (ad es. servizio di sistema) di scrivere su un file, consentire 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/gruppo/altro fallisce. 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 ribadire il mio punto sulla logica necessità di un other categoria nei permessi del file system Unix.
Un tale progetto di file system come sembri 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 deliberato o una patch? Ovvero:i permessi del proprietario/gruppo sono stati progettati e creati insieme con qualche logica o sono venuti uno dopo l'altro per rispondere a un'esigenza?
Sì, questo è un design deliberato che è stato presente in UNIX sin dai primi giorni. È stato implementato su sistemi in cui la memoria è stata 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 everyone gruppo è rappresentato dagli altri flag di sicurezza.
C'è uno scenario in cui lo schema utente/gruppo/altro è utile ma uno schema gruppo/proprietario non sarà sufficiente?
I permessi che uso comunemente per l'accesso ai file sono:(Sto usando i valori in bit per semplicità e perché è così che di solito li imposto.)
600o400:Accesso solo utente (e sì, concedo l'accesso in sola lettura all'utente).640o660:Accesso utente e gruppo.644,666o664:Utente, gruppo e altro accesso. Qualsiasi schema di autorizzazione a due livelli può gestire solo due di questi tre casi. Il terzo richiederebbe ACL.
Per directory e programmi uso comunemente:
700o500:Accesso solo utente750o710:Accesso solo gruppo755,777,775o751:Utente, gruppo e altro accesso. Valgono gli stessi commenti dei file.
Quanto sopra è l'elenco delle impostazioni di autorizzazione più comunemente utilizzate, ma non esaustivo. Le autorizzazioni di cui sopra combinate con un gruppo (a volte con un bit di gruppo appiccicoso sulle directory) sono state sufficienti in tutti i casi in cui avrei potuto utilizzare un ACL.
Come è stato notato sopra, è molto semplice 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.