Mi sono appena imbattuto in qualcosa di inaspettato (per me) per quanto riguarda i permessi dei file su Linux (Arch Linux). Fondamentalmente ho:
userXingroupXfileX userX:groupX ---rwx----
Cosa mi lascia perplesso:non riesco a eseguire alcuna azione (rwx ) su fileX . È giusto? Qualcuno può confermare che questo è effettivamente il comportamento previsto?
Le uniche azioni che posso eseguire sono mv e rm perché ho i permessi di scrittura sulla directory principale.
Il fatto è che ho sempre pensato che queste autorizzazioni collassassero l'una sull'altra, a partire da quella più generale (altro -> gruppo -> utente). In altre parole, se o=rwx a chi importa quali sono le autorizzazioni per il gruppo e l'utente?
Apparentemente non è così, ma per me non ha molto senso; sembra controintuitivo. L'unica cosa a cui questo approccio sembra essere utile è escludere facilmente una persona / gruppo molto specifico, il che non sembra un modo intelligente per farlo (imho). Inoltre, il proprietario (e il gruppo?) dovrebbe essere in grado di chmod comunque giusto? Qualche idea su questo argomento?
Risposta accettata:
Il fatto è che ho sempre pensato che questi permessi collassassero l'uno sull'altro, a cominciare da quello più generale (altro -> gruppo -> utente).
In tal caso, le autorizzazioni "altre" si applicherebbero a tutti.
In altre parole, se o=rwx a chi importa quali sono le autorizzazioni per il gruppo e l'utente?
È diverso dalla tua frase precedente. Qui stai insinuando che le autorizzazioni sono combinate insieme, ad es. quell'utenteX ha il permesso 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 è leggibile dal gruppo, o se il file è leggibile da altri. Ma non è così che funziona. Infatti, o=rwx significa che il rwx le autorizzazioni si applicano ad altri, ma non dice nulla su entità che non sono altre.
Innanzitutto, non importa direttamente a quali gruppi appartenga 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 di gruppo (il GID effettivo e i GID supplementari). I gruppi sono determinati al momento dell'accesso, dal processo di accesso: è il processo di accesso che legge il database del gruppo (ad es. /etc/group ). Gli ID utente e gruppo vengono ereditati dai 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 gruppo supplementare del processo, vengono utilizzati i bit di autorizzazione del gruppo.
- Altrimenti, vengono utilizzati gli altri bit di autorizzazione.
Viene utilizzato un solo set di bit rwx. L'utente ha la precedenza sul gruppo che ha la precedenza sugli altri. In presenza di liste di controllo accessi, 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 gruppo supplementari del processo, vengono utilizzati i bit di autorizzazione del gruppo.
- Altrimenti, vengono utilizzati gli altri bit di autorizzazione.
Quindi -rw----r-- alice interns indica un file che può essere letto e scritto da Alice, e che può essere letto da tutti gli altri utenti tranne gli stagisti. Un file con autorizzazioni e proprietà ----rwx--- alice interns è accessibile solo agli stagisti tranne Alice (che sia una stagista o meno). Poiché Alice può chiamare chmod modificare i permessi, questo non fornisce alcuna sicurezza; è un caso limite. Sui sistemi con ACL, il meccanismo generalizzato consente di rimuovere le autorizzazioni da utenti o gruppi specifici, il che a volte è utile.
L'utilizzo di un singolo set di bit, anziché inserire in ordine tutti i bit per ciascuna azione (lettura, scrittura, esecuzione), presenta diversi vantaggi:
- Ha l'utile effetto di consentire la rimozione dei permessi da un insieme di utenti o gruppi, su sistemi con ACL. Sui sistemi senza ACL, le autorizzazioni possono essere rimosse da un gruppo.
- È più semplice da implementare:controlla un set di bit, piuttosto che combinare più set di bit insieme.
- È più semplice analizzare i permessi di un file, perché sono necessarie meno operazioni.
¹ Possono cambiare quando viene eseguito un processo setuid o setgid. Questo non è correlato al problema in questione.