Crea sito

I permessi dei file

5 / 100

Essendo nato come sistema multiutente, ogni kernel di tipo unix-like come Linux deve fornire dei meccanismi di identificazione dei vari utenti, sulla base dei quali poi possa venire imposto un adeguato controllo degli accessi e delle operazioni che questi possono eseguire all’interno del sistema.

La struttura di sicurezza tradizionale di un sistema unix-like e estremamente semplice, tanto da essere in certi casi considerata troppo primitiva

Essa prevede una distinzione fondamentale fra l’amministratore del sistema, per il quale non esiste nessuna restrizione, e tutti gli altri utenti, per i quali invece vengono effettuati vari controlli, a seconda delle operazioni che vengo-no richieste. all’interno del sistema il kernel identifica ogni utente con un numero identificativo, chiamato user ID o UID. Questo e nullo per l’amministratore e diverso da zero per tutti gli altri utenti. Si tenga presente che quello che conta e comunque l’user ID, non il nome utente, questo infatti e solo un’etichetta che potrebbe essere qualunque ciascun username e’ abbinato ad un user ID, che sarà quello che verra utilizzato dal kernel per tutti i programmi che l’utente lancer una volta entrato nel sistema. Gli utenti poi possono venire raggruppati in gruppi; come per gli utenti ogni gruppo ha un nome (detto groupname) ed un corrispondente identi catore numerico, il group ID o GID. Inoltre ad ogni utente e sempre associato almeno un gruppo, detto gruppo primario o gruppo principale Ogni processo, quando viene lanciato, eredita dal padre l’informazione relativa all’utente per conto del quale viene eseguito e di tutti i gruppi a cui questo appartiene. In questo modo una volta entrati nel sistema tutti i programmi verranno eseguiti per conto dell’utente che ha effettuato la procedura di login. Si evita cosi che utenti diversi possano danneggiarsi fra loro o danneggiare il sistema.

I permessi dei  file

La gestione dei permessi dei file in un sistema unix-like e tutto sommato abbastanza elementare; esistono estensioni che permettono di renderla piu sottile e flessibile, ma nella maggior parte dei casi il controllo di accesso standard e piu che su ciente. In sostanza per il sistema esistono tre livelli di privilegi:

i privilegi dell’utente, indicati con la lettera u, (dall’inglese user).

i privilegi del gruppo, indicati con la lettera g, (dall’inglese group).

i privilegi di tutti gli altri, indicati con la lettera o, (dall’inglese other).

e tre permessi base:

permesso di lettura, indicato con la lettera r, (dall’inglese read).

permesso di scrittura, indicato con la lettera w, (dall’inglese write).

permesso di esecuzione, indicato con la lettera x, (dall’inglese execute).

il cui significato e abbastanza ovvio.

Ogni file e’ associato ad un utente, che e’ detto proprietario del file e ad un gruppo (detto a sua volta gruppo proprietario), per ciascuno dei tre livelli di privilegio (utente, gruppo e altri) e possibile specificare uno dei tre permessi (lettura, scrittura, esecuzione). Questi vengono riportati nella versione estesa dell’output del comando ls:

[email protected]:~/GaPiL$ ls -l    
total 2996    
-rw-r–r– 1 piccardi piccardi67Feb917:01 AUTHORS
-rw-r–r– 1 piccardi piccardi8436Feb917:01 biblio.bib
-rw-r–r– 1 piccardi piccardi29247Feb917:01 build.tex
-rw-r–r– 1 piccardi piccardi7286Feb917:01 ChangeLog
-rw-r–r– 1 piccardi piccardi29941Feb917:01 errors.tex
-rw-r–r– 1 piccardi piccardi17277Feb917:01 fdl.tex
-rw-r–r– 1 piccardi piccardi 297727 Feb917:01 fileadv.tex
-rw-r–r– 1 piccardi piccardi 415730 Feb917:01 filedir.tex
-rw-r–r– 1 piccardi piccardi 205773 Feb917:01 fileio.tex
-rw-r–r– 1 piccardi piccardi5117Feb917:01 gapil.tex
drwxr-xr-x 3 piccardi piccardi4096Feb917:01 htgapil
-rw-r–r– 1 piccardi piccardi7592Feb917:01 htgapil.cfg
-rwxr-xr-x 1 piccardi piccardi175Feb917:01 htmakeindex.sh
drwxr-xr-x 3 piccardi piccardi4096Feb917:01 html
-rwxr-xr-x 1 piccardi piccardi2256Feb917:01 htmlize.sh
drwxr-xr-x 3 piccardi piccardi4096Feb917:01 img
-rw-r–r– 1 piccardi piccardi84338Feb917:01 intro.tex

La lettura dell’output di questo comando ci permette di vedere che i sorgenti dei programmi contenuti nella directory in oggetto hanno quelli che sono in genere i permessi di default per i le di dati, si ha cioe il permesso di scrittura solo per il proprietario, quello di lettura per tutti quanti (proprietario, gruppo e altri) e l’assenza completa del permesso di esecuzione.

In generale un utente potrà effettuare solo le azioni per le quali ha i permessi, nel caso dei permessi appena illustrati questo comporta che un utente puo leggere i file di un altro ma non puo modificarli o cancellarli.

In realtà il meccanismo del controllo e abbastanza peculiare, e questo, se non capito fino in fondo, puo dar luogo a qualche confusione.

La verifica dei permessi di accesso ad un file prevede infatti i seguenti passi, eseguiti esattamente in questa sequenza:

1 se il processo viene eseguito dall'amministratore l'accesso viene sempre garantito, senza che sia eseguito nessun controllo;

2 se il processo viene eseguito dal proprietario del file allora:

2-1 vengono controllati i permessi corrispondenti all’utente (i primi tre di g. 1.5), e 2-2 se questi sono assegnati per l’operazione richiesta, l’accesso e consentito; altrimenti l’accesso è negato;

3 se il processo viene eseguito da un utente che appartiene al gruppo proprietario del file allora:

3-1 vengono controllati i permessi corrispondenti al gruppo (i centrali in g. 1.5), e se questi sono assegnati per l’operazione richiesta, l’accesso e consentito; altrimenti l’accesso e negato;

4 se il processo viene eseguito da un qualunque altro utente allora:

4-1 vengono controllati i permessi corrispondenti a tutti gli altri (gli ultimi di g. 1.5), e se questi sono assegnati per l’operazione richiesta, l’accesso e consentito; altrimenti l’accesso e negato.

Si noti bene come in questa sequenza di controlli, una volta che la decisione riguardo l’accesso e presa, i passi successivi non vengono piu eseguiti.

Tutto cio significa ad esempio che se un utente non ha il permesso di scrittura per un proprio file, questi non potra scriverci, anche qualora il permesso di scrittura per il gruppo o per tutti gli altri fossero garantiti.

Vale la pena anche sottolineare di nuovo come i controlli siano eseguiti per tutti gli utenti eccetto l’amministratore, che non e soggetto a nessun tipo di restrizione e puo quindi eseguire qualunque operazione. I permessi inoltre hanno un signi cato leggermente diverso quando si applicano agli altri tipi di le illustrati in tab. 1.1.

Nel caso di le di dispositivo, fifo e socket ad esempio il permesso di esecuzione e ignorato, mentre per i link simbolici tutti i permessi sono totalmente ignorati (e questo il motivo per cui un collegamento simbolico li presenta come tutti attivi) e quelli che vengono presi in considerazione sono quelli del le a cui il collegamento fa riferimento. Il piu complesso da capire resta comunque il permesso di esecuzione che normalmente, come per la directory img dell’esempio precedente, e sempre presente. Le directory non sono programmi ed ovviamente \eseguire” una lista di le non ha nessun signi cato. Il kernel percio usa questo permesso dandogli un signi cato particolare, che e quello di poter \attraversare” la directory nella risoluzione del nome di un file.

Si tenga presente che tutto cio resta valido anche in presenza del permesso di lettura sulla directory, che signi ca solo che e possibile elencarne il contenuto. Questi tre permessi aggiuntivi nascono per modi care il comportamento del sistema nell’e-secuzione dei programmi.

Per questo normalmente sono sempre abbinati al permesso di esecuzione, ed hanno e etto solo se vengono applicati a dei binari eseguibili (nel caso siano presenti su uno script come misura di sicurezza vengono ignorati).

Translate »