Il fatto è che ho sempre pensato che queste autorizzazioni collassassero l'una sull'altra, a partire da quella più generale (altro -> gruppo -> utente).
In tal caso, le autorizzazioni "altro" si applicherebbero a tutti.
In altre parole, se o = rwx chi se ne frega di quali siano le convinzioni per gruppo e utente?
È diverso dalla frase precedente. Qui stai sottintendendo che le autorizzazioni sono o messe insieme, ad esempio che userX ha l'autorizzazione di lettura se userX possiede il file e il file è leggibile dall'utente o se un gruppo a cui appartiene userX possiede il file e il file è gruppo leggibile o se il file è leggibile in altro modo. Ma non è così che funziona. In realtà, o=rwxsignifica che le rwxautorizzazioni si applicano ad altri, ma non dice nulla su entità che non sono altre.
Innanzitutto, non importa direttamente a quali gruppi appartiene un utente. Il kernel non ha una nozione di utenti appartenenti a gruppi. Ciò che il kernel mantiene è, per ogni processo, un ID utente (l' UID effettivo ) e un elenco di ID gruppo (il GID effettivo e i GID supplementari). I gruppi sono determinati al momento dell'accesso, tramite il processo di accesso: è il processo di accesso che legge il database del gruppo (ad es /etc/group.). Gli ID utente e di gruppo sono ereditati da processi figlio¹.
Quando un processo tenta di aprire un file, con le autorizzazioni Unix tradizionali:
- Se l'utente proprietario del file è l'UID effettivo del processo, vengono utilizzati i bit di autorizzazione dell'utente.
- Altrimenti, se il gruppo proprietario del file è il GID effettivo del processo o uno degli ID di gruppo supplementare del processo, vengono utilizzati i bit di autorizzazione del gruppo.
- Altrimenti, vengono utilizzati gli altri bit di autorizzazione.
Viene mai utilizzato un solo set di bit rwx. L'utente ha la precedenza sul gruppo che ha la precedenza sull'altro. Quando sono presenti elenchi di controllo di accesso , l'algoritmo sopra descritto è generalizzato:
- Se nel file è presente un ACL per l'UID effettivo del processo, viene utilizzato per determinare se l'accesso è concesso.
- Altrimenti, se nel file è presente un ACL per il GID effettivo del processo o uno degli ID di gruppo supplementare del processo, vengono utilizzati i bit di autorizzazione del gruppo.
- Altrimenti, vengono utilizzati gli altri bit di autorizzazione.
Vedi anche Precedenza di ACLS quando un utente appartiene a più gruppi per maggiori dettagli su come vengono utilizzate le voci ACL, incluso l'effetto della maschera.
-rw----r-- alice internsIndica quindi un file che può essere letto e scritto da Alice e che può essere letto da tutti gli altri utenti ad eccezione degli stagisti. Un file con autorizzazioni e proprietà ----rwx--- alice internsè accessibile solo agli stagisti ad eccezione di Alice (che sia o meno stagista). Poiché Alice può chiamare chmodper modificare le autorizzazioni, ciò non fornisce alcuna sicurezza; è un caso limite. Sui sistemi con ACL, il meccanismo generalizzato consente di rimuovere autorizzazioni da utenti specifici o gruppi specifici, che a volte è utile.
L'utilizzo di un singolo set di bit, anziché ordinare tutti i bit per ciascuna azione (lettura, scrittura, esecuzione), presenta numerosi vantaggi:
- Ha l'effetto utile di consentire la rimozione delle autorizzazioni da un insieme di utenti o gruppi, sui sistemi con ACL. Sui sistemi senza ACL, le autorizzazioni possono essere rimosse da un gruppo.
- È più semplice da implementare: controlla una serie di bit, piuttosto che combinare più serie di bit insieme.
- Analizzare le autorizzazioni di un file è più semplice, poiché sono coinvolte meno operazioni.
¹ Possono cambiare quando viene eseguito un processo setuid o setgid. Questo non è correlato al problema in questione.