-Questi permessi vengono usati in maniera diversa dalle varie funzioni, e a
-seconda che si riferiscano a file, link simbolici o directory, qui ci
-limiteremo ad un riassunto delle regole generali, entrando nei
-dettagli più avanti.
-
-La prima regola è che per poter accedere ad un file attraverso il suo pathname
-occorre il permesso di esecuzione in ciascuna delle directory che compongono
-il pathname, e lo stesso vale per aprire un file nella directory corrente (per
-la quale appunto serve il diritto di esecuzione).
-
-Per una directory infatti il permesso di esecuzione ha il significato
-specifico che essa può essere attraversata nella risoluzione del pathname, ed
-è distinto dal permesso di lettura che invece implica che si può leggere il
-contenuto della directory. Questo significa che se si ha il permesso di
-esecuzione senza permesso di lettura si potrà lo stesso aprire un file in una
-directory (se si hanno i permessi opportuni per il medesimo) ma non si potrà
-vederlo con \cmd{ls} (per crearlo occorrerà anche il permesso di scrittura per
-la directory).
-
-Avere il permesso di lettura per un file consente di aprirlo con le opzioni di
-sola lettura (\macro{O\_RDONLY}) o di lettura-scrittura (\macro{O\_RDWR}) e
-leggerne il contenuto. Avere il permesso di scrittura consente di aprire un
-file in sola scrittura (\macro{O\_WRONLY}) o lettura-scrittura
-(\macro{O\_RDWR}) e modificarne il contenuto, lo stesso permesso è necessario
-per poter troncare il file con l'opzione \macro{O\_TRUNC}.
-
-Non si può creare un file fintanto che non si disponga del permesso di
-esecuzione e di quello di scrittura per la directory di destinazione; gli
-stessi permessi occorrono per cancellare un file da una directory (si ricordi
-che questo non implica necessariamente la rimozione fisica del file), non è
-necessario nessun tipo di permesso per il file stesso (infatti esso non viene
-toccato, viene solo modificato il contenuto della directory, rimuovendo la
-voce che ad esso fa rifermento).
-
-Per poter eseguire un file (che sia un programma compilato od uno script di
-shell), occorre il permesso di esecuzione per il medesimo, inoltre solo i file
-regolari possono essere eseguiti.
-
-I permessi per un link simbolico sono ignorati, contano quelli del file a cui
-fa riferimento; per questo in genere \cmd{ls} per un link simbolico riporta
-tutti i permessi come concessi; utente e gruppo a cui esso appartiene vengono
-ignorati quando il link viene risolto, vengono controllati solo quando viene
-richiesta la rimozione del link e quest'ultimo è in una directory con lo
-\textsl{sticky bit} settato (si veda \secref{sec:filedir_sticky}).
-
-La procedura con cui il kernel stabilisce se un processo possiede un certo
-permesso (di lettura, scrittura o esecuzione) si basa sul confronto fra
-l'utente e il gruppo a cui il file appartiene (i valori di \var{st\_uid} e
-\var{st\_gid} accennati in precedenza) e l'\textit{effective user id},
-l'\textit{effective group id} e gli eventuali \textit{supplementary group id}
-del processo.
-
-Per una spiegazione dettagliata degli identificatori associati ai processi si
-veda \secref{sec:prochand_perms}; normalmente, a parte quanto vedremo in
-\secref{sec:filedir_suid_sgid}, l'\textit{effective user id} e
-l'\textit{effective group id} corrispondono a uid e gid dell'utente che ha
-lanciato il processo, mentre i \textit{supplementary group id} sono quelli dei
-gruppi cui l'utente appartiene.
-
-% Quando un processo cerca l'accesso al file esso controlla i propri uid e gid
-% confrontandoli con quelli del file e se l'operazione richiesta è compatibile
-% con i permessi associati al file essa viene eseguita, altrimenti viene
-% bloccata ed è restituito un errore di \texttt{EPERM}. Questo procedimento non
-% viene eseguito per l'amministratore di sistema (il cui uid è zero) il quale
-% a
-% pertanto accesso senza restrizione a qualunque file del sistema.
-
-% In realtà il procedimento è più complesso di quanto descritto in maniera
-% elementare qui; inoltre ad un processo sono associati diversi identificatori,
-% torneremo su questo in maggiori dettagli in seguito in
-% \secref{sec:proc_perms}.
-
-I passi attraverso i quali viene stabilito se il processo possiede il diritto
-di accesso sono i seguenti:
-\begin{itemize}
-\item Se l'\textit{effective user id} del processo è zero (corrispondente
- all'amministratore) l'accesso è sempre garantito senza nessun ulteriore
- controllo. Per questo motivo \textsl{root} ha piena libertà di accesso a
- tutti i file.
-\item Se l'\textit{effective user id} del processo è uguale all'uid del
- proprietario del file (nel qual caso si dice che il processo è proprietario
- del file) allora:
- \begin{itemize}
- \item se il relativo\footnote{per relativo si intende il bit di user-read se
- il processo vuole accedere in scrittura, quello di user-write per
- l'accesso in scrittura, etc.} bit dei permessi d'accesso dell'utente è
- settato, l'accesso è consentito
- \item altrimenti l'accesso è negato
- \end{itemize}
-\item Se l'\textit{effective group id} del processo o uno dei
- \textit{supplementary group id} dei processi corrispondono al gid del file
- allora:
- \begin{itemize}
- \item se il bit dei permessi d'accesso del gruppo è settato, l'accesso è
- consentito,
- \item altrimenti l'accesso è negato
- \end{itemize}
-\item se il bit dei permessi d'accesso per tutti gli altri è settato,
- l'accesso è consentito, altrimenti l'accesso è negato.
-\end{itemize}
-
-Si tenga presente che questi passi vengono eseguiti esattamente in
-quest'ordine. Questo vuol dire che se un processo è il proprietario di un file
-l'accesso è consentito o negato solo sulla base dei permessi per l'utente; i
-permessi per il gruppo non vengono neanche controllati; lo stesso vale se il
-processo appartiene ad un gruppo appropriato, in questo caso i permessi per
-tutti gli altri non vengono controllati.
-
-
-\subsection{I bit \textsl{suid} e \textsl{sgid}}
-\label{sec:filedir_suid_sgid}
-
-Come si è accennato (in \secref{sec:filedir_perm_overview}) nei dodici bit del
-campo \var{st\_mode} usati per il controllo di accesso oltre ai bit dei
-permessi veri e propri, ci sono altri tre bit che vengono usati per indicare
-alcune proprietà speciali dei file. Due di questi sono i bit detti
-\textsl{suid} (o \textit{set-user-ID bit}) e \textsl{sgid} (o
-\textit{set-group-ID bit}) che sono identificati dalle constanti
-\macro{S\_ISUID} e \macro{S\_ISGID}.
-
-Come spiegato in dettaglio in \secref{sec:prochand_exec}, quando si lancia un
-programma il comportamendo normale del kernel è quello di settare
-l'\textit{effective user id} e l'\textit{effective group id} del nuovo
-processo all'uid e al gid del processo corrente, che normalmente corrispondono
-dell'utente con cui si è entrati nel sistema.
-
-Se però il file del programma (che ovviamente deve essere eseguibile) ha il
-bit \textsl{suid} settato, il kernel assegnerà come \textit{effective user id}
-al nuovo processo l'uid del proprietario del file al posto dell'uid del
-processo originario. Avere il bit \textsl{sgid} settato ha lo stesso effetto
-sull'\textit{effective group id} del processo.
-
-I bit \textsl{suid} e \textsl{sgid} vengono usati per permettere agli utenti
-normali di usare programmi che abbisognano di privilegi speciali; l'esempio
-classico è il comando \cmd{passwd} che ha la necessità di modificare il file
-delle password, quest'ultimo ovviamente può essere scritto solo
-dall'amministratore, ma non è necessario chiamare l'amministratore per
-cambiare la propria password. Infatti il comando \cmd{passwd} appartiene a root
-ma ha il suid bit settato per cui quando viene lanciato da un utente normale
-parte con i privilegi di root.
-
-Chiaramente avere un processo che ha privilegi superiori a quelli che avrebbe
-normalmente l'utente che lo ha lanciato comporta vari rischi, e questo tipo di
-programmi devono essere scritti accuratamente (torneremo sull'argomento in
-\secref{sec:prochand_perms}) per evitare che possano essere usati per
-guadagnare privilegi non consentiti.
-
-La presenza dei bit \textsl{suid} e \textsl{sgid} su un file può essere
-rilevata con il comando \cmd{ls -l}, in tal caso comparirà la lettera \cmd{s}
-al posto della \cmd{x} in corrispondenza dei permessi di utente o gruppo. La
-stessa lettera \cmd{s} può essere usata nel comando \cmd{chmod} per settare
-questi bit. Infine questi bit possono essere controllati all'interno di
-\var{st\_mode} con l'uso delle due costanti \macro{S\_ISUID} e
-\macro{S\_IGID}, i cui valori sono riportati in
-\tabref{tab:filedir_file_mode_flags}.
-
-Gli stessi bit vengono ad assumere in significato completamente diverso per le
-directory, normalmente infatti Linux usa la convenzione di SVR4 per indicare
-con questi bit l'uso della semantica BSD nella creazione di nuovi file (si
-veda \secref{sec:filedir_ownership} per una spiegazione dettagliata al
-proposito).
-
-Infine Linux utilizza il bit \textsl{sgid} per una ulteriore estensione
-mutuata da SVR4. Il caso in cui il file abbia il bit \textsl{sgid} settato ma
-non il corrispondente bit di esecuzione viene utilizzato per attivare per
-quel file il \textit{mandatory locking} (argomento che affronteremo nei
-dettagli in \secref{sec:xxx_mandatory_lock}).
-
-
-\subsection{Il bit \textsl{sticky}}
-\label{sec:filedir_sticky}
-
-L'ultimo dei bit rimanenti, identificato dalla costante \macro{S\_ISVTX}, è in
-parte un rimasuglio delle origini dei sistemi unix. A quell'epoca infatti la
-memoria virtuale e l'accesso ai files erano molto meno sofisticati e per
-ottenere la massima velocità possibile per i programmi usati più comunemente
-si poteva settare questo bit.
-
-L'effetto di questo bit era che il segmento di testo del programma (si veda
-\secref{sec:proc_mem_layout} per i dettagli) veniva scritto nella swap la
-prima volta che questo veniva lanciato, e vi permaneva fino al riavvio della
-mecchina (da questo il nome di \textsl{sticky bit}); essendo la swap un file
-continuo indicizzato direttamente in questo modo si poteva risparmiare in
-tempo di caricamento rispetto alla ricerca del file su disco.
-
-Ovviamente per evitare che gli utenti potessero intasare la swap solo
-l'amministratore era in grado di settare questo bit, che venne chiamato anche
-\textit{saved text bit}, da cui deriva il nome della costante. Le attuali
-implementazioni di memoria virtuale e filesystem rendono sostanzialmente
-inutile questo procedimento. Lo \textsl{sticky bit} è indicato attraverso la
-lettera \cmd{t} al posto della \cmd{x} nei permessi per gli altri.
-
-Benché ormai non venga più utilizzato per i file, lo \textsl{sticky bit} ha
-assunto un uso corrente per le directory\footnote{lo \textsl{sticky bit} è una
- estensione non definita nello standard POSIX, Linux però la supporta, così
- come BSD e SVR4}, in questo caso se il bit è settato un file potrà essere
-rimosso dalla directory soltanto se l'utente ha il permesso di scrittura ed
-inoltre è vera una delle seguenti condizioni:
-\begin{itemize}
-\item l'utente è proprietario del file
-\item l'utente è proprietario della directory
-\item l'utente è l'amministratore
-\end{itemize}
-un classico esempio di directory che ha questo bit settato è \file{/tmp}, i
-permessi infatti di solito sono settati come:
-\begin{verbatim}
-drwxrwxrwt 6 root root 1024 Aug 10 01:03 /tmp
-\end{verbatim}
-in questo modo chiunque può leggere, scrivere ed eseguire i file temporanei
-ivi memorizzati, sia crearne di nuovi, ma solo l'utente che ha creato un file
-nella directory potrà cancellarlo o rinominarlo, evitando così che utente
-possa, più o meno consapevolemnte, cancellare i file degli altri.
-
-
-\subsection{La titolarità di nuovi file e directory}
-\label{sec:filedir_ownership}
-
-Vedremo in \secref{sec:fileunix_base_func} quali sono le funzioni per creare
-nuovi file, ma se è possibile specificare in sede di creazione quali permessi
-applicare ad un nuovo file, non si può indicare a quale utente e gruppo esso
-deve appartenere. Lo stesso problema di presenta per la creazione di nuove
-directory (procedimento descritto in \secref{sec:filedir_dir_creat_rem}).
-
-Lo standard POSIX prescrive che l'uid del nuovo file corrisponda
-all'\textit{effective user id} del processo che lo crea; per il gid invece
-prevede due diverse possibilità:
-\begin{itemize}
-\item il gid del file corrisponde all'\textit{effective group id} del processo
-\item il gid del file corrisponde al gid della directory in cui esso è creato
-\end{itemize}
-in genere BSD usa sempre la seconda possibilità, che viene per questo chiamata
-semantica BSD. Linux invece segue quella che viene chiamata semantica SVR4; di
-norma cioè il nuovo file viene creato, seguendo la prima opzione, con il gid
-del processo, se però la directory in cui viene creato il file ha il bit sgid
-settato allora viene usata la seconda opzione..
-
-Usare la semantica BSD ha il vantaggio che il gid viene sempre automaticamente
-propagato, restando coerente a quello della directory di partenza, in tutte le
-sottodirectory. La semantica SVR4 offre una maggiore possibilità di scelta, ma
-per ottenere lo stesso risultato necessita che per le nuove directory venga
-anche propagato anche il bit sgid. Questo è comunque il comportamento di
-default di \func{mkdir}, ed é in questo modo ad esempio che Debian assicura
-che le sottodirectory create nelle home di un utente restino sempre con il gid
-del gruppo primario dello stesso.
-
-
-\subsection{La funzione \texttt{access}}
-\label{sec:filedir_access}
-
-Come detto in \secref{sec:filedir_access_control} il controllo di accesso ad
-un file viene fatto usando \textit{effective user id} e \textit{effective
- group id} del processo, ma ci sono casi in cui si può voler effettuare il
-controllo usando il \textit{real user id} e il \textit{real group id} (cioè
-l'uid dell'utente che ha lanciato il programma, che, come accennato in
-\secref{sec:filedir_suid_sgid} e spiegato in \secref{sec:prochand_perms} non è
-detto sia uguale all'\textit{effective user id}). Per far questo si può usare
-la funzione \func{access}, il cui prototipo è:
-