X-Git-Url: https://gapil.gnulinux.it/gitweb/?a=blobdiff_plain;f=filedir.tex;h=2ca508fd36d222356e6536dff9734594232127bd;hb=260bf7cea27648dc1d5a81b55b996fc4f710e507;hp=9d41573b157ede2149102e37b992416e36846cf4;hpb=4de1dd4a3e26e5ff1ccc64530927bae308b80688;p=gapil.git diff --git a/filedir.tex b/filedir.tex index 9d41573..2ca508f 100644 --- a/filedir.tex +++ b/filedir.tex @@ -612,7 +612,7 @@ creare file regolari e fifo; l'argomento \param{mode} specifica il tipo di file che si vuole creare ed i relativi permessi, secondo i valori riportati in tab.~\ref{tab:file_mode_flags}, che vanno combinati con un OR binario. I permessi sono comunque modificati nella maniera usuale dal valore di -\var{umask} (si veda sez.~\ref{sec:file_perm_management}). +\itindex{umask} \textit{umask} (si veda sez.~\ref{sec:file_perm_management}). Per il tipo di file può essere specificato solo uno fra: \const{S\_IFREG} per un file regolare (che sarà creato vuoto), \const{S\_IFBLK} per un dispositivo @@ -652,7 +652,7 @@ sez.~\ref{sec:ipc_named_pipe}) lo standard POSIX specifica l'uso della funzione La funzione crea la fifo \param{pathname} con i permessi \param{mode}. Come per \func{mknod} il file \param{pathname} non deve esistere (neanche come link simbolico); al solito i permessi specificati da \param{mode} vengono -modificati dal valore di \var{umask}. +modificati dal valore di \itindex{umask} \textit{umask}. @@ -1399,6 +1399,7 @@ Si noti come i vari membri della struttura siano specificati come tipi primitivi del sistema (di quelli definiti in tab.~\ref{tab:intro_primitive_types}, e dichiarati in \file{sys/types.h}). +% TODO: aggiornare con i cambiamenti ai tempi fatti con il 2.6 \subsection{I tipi di file} \label{sec:file_types} @@ -1423,13 +1424,13 @@ riportato in tab.~\ref{tab:file_type_macro}. \textbf{Macro} & \textbf{Tipo del file} \\ \hline \hline - \macro{S\_ISREG(m)} & File normale.\\ - \macro{S\_ISDIR(m)} & Directory.\\ - \macro{S\_ISCHR(m)} & Dispositivo a caratteri.\\ - \macro{S\_ISBLK(m)} & Dispositivo a blocchi.\\ - \macro{S\_ISFIFO(m)} & Fifo.\\ - \macro{S\_ISLNK(m)} & Link simbolico.\\ - \macro{S\_ISSOCK(m)} & Socket.\\ + \macro{S\_ISREG(m)} & file normale.\\ + \macro{S\_ISDIR(m)} & directory.\\ + \macro{S\_ISCHR(m)} & dispositivo a caratteri.\\ + \macro{S\_ISBLK(m)} & dispositivo a blocchi.\\ + \macro{S\_ISFIFO(m)} & fifo.\\ + \macro{S\_ISLNK(m)} & link simbolico.\\ + \macro{S\_ISSOCK(m)} & socket.\\ \hline \end{tabular} \caption{Macro per i tipi di file (definite in \texttt{sys/stat.h}).} @@ -1969,7 +1970,7 @@ di accesso sono i seguenti: 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 + il processo vuole accedere in lettura, quello di user-write per l'accesso in scrittura, ecc.} bit dei permessi d'accesso dell'utente è impostato, l'accesso è consentito \item altrimenti l'accesso è negato @@ -1981,7 +1982,7 @@ di accesso sono i seguenti: consentito, \item altrimenti l'accesso è negato \end{itemize*} -\item se il bit dei permessi d'accesso per tutti gli altri è impostato, +\item Se il bit dei permessi d'accesso per tutti gli altri è impostato, l'accesso è consentito, altrimenti l'accesso è negato. \end{enumerate} @@ -2182,6 +2183,8 @@ eseguendo un programma coi privilegi di un altro utente (ad esempio attraverso l'uso del \itindex{suid~bit} \textit{suid bit}) che vuole controllare se l'utente originale ha i permessi per accedere ad un certo file. +% TODO documentare euidaccess (e eaccess) + Per cambiare i permessi di un file il sistema mette ad disposizione due funzioni \funcd{chmod} e \funcd{fchmod}, che operano rispettivamente su un filename e su un file descriptor, i loro prototipi sono: @@ -2305,17 +2308,22 @@ dell'interfaccia standard ANSI C che non prevede l'esistenza di utenti e gruppi, ed inoltre il problema si pone anche per l'interfaccia nativa quando i permessi non vengono indicati esplicitamente. -In tutti questi casi l'unico riferimento possibile è quello della modalità di -apertura del nuovo file (lettura/scrittura o sola lettura), che però può -fornire un valore che è lo stesso per tutti e tre i permessi di -sez.~\ref{sec:file_perm_overview} (cioè $666$ nel primo caso e $222$ nel -secondo). Per questo motivo il sistema associa ad ogni processo\footnote{è - infatti contenuta nel campo \var{umask} della struttura \struct{fs\_struct}, - vedi fig.~\ref{fig:proc_task_struct}.} una maschera di bit, la cosiddetta -\textit{umask}, che viene utilizzata per impedire che alcuni permessi possano -essere assegnati ai nuovi file in sede di creazione. I bit indicati nella -maschera vengono infatti cancellati dai permessi quando un nuovo file viene -creato. +\itindbeg{umask} + +Per le funzioni dell'interfaccia standard ANSI C l'unico riferimento possibile +è quello della modalità di apertura del nuovo file (lettura/scrittura o sola +lettura), che però può fornire un valore che è lo stesso per tutti e tre i +permessi di sez.~\ref{sec:file_perm_overview} (cioè $666$ nel primo caso e +$222$ nel secondo). Per questo motivo il sistema associa ad ogni +processo\footnote{è infatti contenuta nel campo \var{umask} della struttura + \struct{fs\_struct}, vedi fig.~\ref{fig:proc_task_struct}.} una maschera di +bit, la cosiddetta \textit{umask}, che viene utilizzata per impedire che +alcuni permessi possano essere assegnati ai nuovi file in sede di creazione. I +bit indicati nella maschera vengono infatti cancellati dai permessi quando un +nuovo file viene creato.\footnote{l'operazione viene fatta sempre: anche + qualora si indichi esplicitamente un valore dei permessi nelle funzioni di + creazione che lo consentono, i permessi contenuti nella \textit{umask} + verranno tolti.} La funzione che permette di impostare il valore di questa maschera di controllo è \funcd{umask}, ed il suo prototipo è: @@ -2336,6 +2344,7 @@ $022$). In questo modo voluti. Di norma questo valore viene impostato una volta per tutte al login a $022$, e gli utenti non hanno motivi per modificarlo. +\itindend{umask} \subsection{La gestione della titolarità dei file} @@ -2611,7 +2620,7 @@ classi di attributi riportate in tab.~\ref{tab:extended_attribute_class}. \begin{table}[htb] \centering \footnotesize - \begin{tabular}{|c|p{8cm}|} + \begin{tabular}{|c|p{10cm}|} \hline \textbf{Nome} & \textbf{Descrizione} \\ \hline @@ -2951,7 +2960,7 @@ le esigenze pi rispondere in maniera adeguata a situazioni che richiedono una gestione complessa dei permessi di accesso.\footnote{già un requisito come quello di dare accesso in scrittura ad alcune persone ed in sola lettura ad altre non - si può soddisfare in maniera soddisfacente.} + si può soddisfare in maniera semplice.} Per questo motivo erano state progressivamente introdotte nelle varie versioni di Unix dei meccanismi di gestione dei permessi dei file più flessibili, nella @@ -2980,12 +2989,157 @@ standard POSIX 1003.1e. Anche in questo caso le funzioni di questa libreria non fanno parte delle \acr{glibc} e devono essere installate a parte;\footnote{la versione corrente della libreria è \texttt{libacl1}, e nel caso si usi Debian la si può - installare con il pacchetto omonimo ed il collegato \texttt{libacl1-dev}.} -pertanto se un programma le utilizza si dovrà indicare esplicitamente l'uso -della libreria \texttt{libacl} invocando il compilatore con l'opzione -\texttt{-lacl}. + installare con il pacchetto omonimo e con il collegato \texttt{libacl1-dev} + per i file di sviluppo.} pertanto se un programma le utilizza si dovrà +indicare esplicitamente l'uso della libreria \texttt{libacl} invocando il +compilatore con l'opzione \texttt{-lacl}. Si tenga presente inoltre che per +poterle utilizzare le ACL devono essere attivate esplicitamente montando il +filesystem\footnote{che deve supportarle, ma questo è ormai vero per + praticamente tutti i filesystem più comuni, con l'eccezione di NFS per il + quale esiste però un supporto sperimentale.} su cui le si vogliono +utilizzare con l'opzione \texttt{acl} attiva. Dato che si tratta di una +estensione è infatti opportuno utilizzarle soltanto laddove siano necessarie. + +Una ACL è composta da un insieme di voci, e ciascuna voce è a sua volta +costituita da un \textsl{tipo}, da un eventuale +\textsl{qualificatore},\footnote{deve essere presente soltanto per le voci di + tipo \const{ACL\_USER} e \const{ACL\_GROUP}.} e da un insieme di permessi. +Ad ogni oggetto sul filesystem si può associare una ACL che ne governa i +permessi di accesso, detta \textit{access ACL}. Inoltre per le directory si +può impostare una ACL aggiuntiva, detta \textit{default ACL}, che serve ad +indicare quale dovrà essere la ACL assegnata di default nella creazione di un +file all'interno della directory stessa. Come avviene per i permessi le ACL +possono essere impostate solo del proprietario del file, o da un processo con +la capability \index{capabilities} \const{CAP\_FOWNER}. +\begin{table}[htb] + \centering + \footnotesize + \begin{tabular}{|l|p{8cm}|} + \hline + \textbf{Tipo} & \textbf{Descrizione} \\ + \hline + \hline + \const{ACL\_USER\_OBJ} & voce che contiene i diritti di accesso del + proprietario del file.\\ + \const{ACL\_USER} & voce che contiene i diritti di accesso per + l'utente indicato dal rispettivo + qualificatore.\\ + \const{ACL\_GROUP\_OBJ}& voce che contiene i diritti di accesso del + gruppo proprietario del file.\\ + \const{ACL\_GROUP} & voce che contiene i diritti di accesso per + il gruppo indicato dal rispettivo + qualificatore.\\ + \const{ACL\_MASK} & voce che contiene la maschera dei massimi + permessi di accesso che possono essere garantiti + da voci del tipo \const{ACL\_USER}, + \const{ACL\_GROUP} e \const{ACL\_GROUP\_OBJ}.\\ + \const{ACL\_OTHER} & voce che contiene i diritti di accesso di chi + non corrisponde a nessuna altra voce dell'ACL.\\ + \hline + \end{tabular} + \caption{Le costanti che identificano i tipi delle voci di una ACL.} + \label{tab:acl_tag_types} +\end{table} +L'elenco dei vari tipi di voci presenti in una ACL, con una breve descrizione +del relativo significato, è riportato in tab.~\ref{tab:acl_tag_types}. Tre di +questi tipi, \const{ACL\_USER\_OBJ}, \const{ACL\_GROUP\_OBJ} e +\const{ACL\_OTHER}, corrispondono direttamente ai tre permessi ordinari dei +file (proprietario, gruppo proprietario e tutti gli altri) e una ACL valida +deve sempre contenere una ed una sola voce per ciascuno di questi tipi. + +Una ACL può poi contenere un numero arbitrario di voci di tipo +\const{ACL\_USER} e \const{ACL\_GROUP}, ciascuna delle quali indicherà i +permessi assegnati all'utente e al gruppo indicato dal relativo qualificatore; +ovviamente un utente o gruppo potranno essere indicati una sola volta +all'interno di una ACL. Inoltre se in una ACL esiste una voce di uno di questi +due tipi è obbligatoria anche la presenza di una ed una sola voce di tipo +\const{ACL\_MASK}, che negli altri casi è opzionale. + +Quest'ultimo tipo di voce contiene la maschera dei permessi che possono essere +assegnati tramite voci di tipo \const{ACL\_USER}, \const{ACL\_GROUP} e +\const{ACL\_GROUP\_OBJ}, se in una di queste voci si fosse specificato un +permesso non presente in \const{ACL\_MASK} questo verrebbe ignorato. L'uso di +\const{ACL\_MASK} è di particolare utilità quando associata ad una +\textit{default ACL} di una directory in quanto i permessi così specificati +vengono ereditati da tutti i file creati nella stessa, ottenendo una sorta di +\itindex{umask} \textit{umask} associata ad un oggetto sul filesystem +piuttosto che a un processo. + +Dato che le ACL vengono a costituire una estensione dei permess ordinari, uno +dei problemi che si erano posti nella loro standardizzazione era appunto +quello della corrispondenza fra questi e le ACL. Come accennato i permessi +ordinari vengono mappati le tre voci di tipo \const{ACL\_USER\_OBJ}, +\const{ACL\_GROUP\_OBJ} e \const{ACL\_OTHER} che devono essere presenti in +qualunque ACL; un cambiamento ad una di queste voci viene automaticamente +riflesso sui permessi ordinari dei file\footnote{per permessi ordinari si + intende quelli mantenuti nell'\textit{inode}, che devono restare dato che un + filesystem può esseere montato senza abilitare le ACL.} e viceversa. In +realtà la mappatura è diretta solo per le voci \const{ACL\_USER\_OBJ} e +\const{ACL\_OTHER}, nel caso di \const{ACL\_GROUP\_OBJ} questo vale fintanto +che non è presente una voce di tipo \const{ACL\_MASK}, nel qual caso valgono +invece i permessi in essa specificati.\footnote{questo diverso comportamento a + seconda delle condizioni è stato introdotto dalla standardizzazione + \textit{POSIX 1003.1e Draft 17} per mantenere il comportamento invariato sui + sistemi dotati di ACL per tutte quelle applicazioni che sono conformi + soltanto all'ordinario standard \textit{POSIX 1003.1}.} + +Un secondo aspetto dell'incidenza delle ACL sul comportamento del sistema è +quello relativo alla creazione di nuovi file,\footnote{o oggetti sul + filesystem, il comportamento discusso vale per le funzioni \func{open} e + \func{creat} (vedi sez.~\ref{sec:file_open}), \func{mkdir} (vedi + sez.~\ref{sec:file_dir_creat_rem}), \func{mknod} e \func{mkfifo} (vedi + sez.~\ref{sec:file_mknod}).} che come accennato può essere modificato dalla +presenza di una default ACL sulla directory che contiene quel file. Se questa +non c'è valgono le regole illustrate in sez.~\ref{sec:file_perm_management} +per cui essi sono determinati dalla \itindex{umask} \textit{umask} del +processo, e la sola differenza è che i permessi ordinari da esse risultanti +vengono automaticamente rimappati su una ACL di accesso assegnata al nuovo +file che contiene solo le tre voci di tipo \const{ACL\_USER\_OBJ}, +\const{ACL\_GROUP\_OBJ} e \const{ACL\_OTHER}. + +Se invece è presente una ACL di default sulla directory che contiene il nuovo +file questa diventerà la sua ACL di accesso, a meno di non aver indicato nelle +funzioni di creazione che lo consentono uno specifico insieme di +permessi.\footnote{tutte le funzioni citate in precedenza supportano un + argomento \var{mode} che indichi un insieme di permssi iniziale.} In tal +caso quelli non presenti in tale insieme saranno eliminati dalle voci +corrispondenti nella ACL. + +Ovviamente la presenza della ACL modifica anche le regole del controllo di +accesso ai file illustrate in sez.~\ref{sec:file_perm_overview}; per il +controllo vengono sempre utilizzati gli identificatori del gruppo +\textit{effective} del processo, ed i passi attraverso i quali viene stabilito +se esso ha diritto di accesso sono i seguenti: +\begin{enumerate} +\item Se l'user-ID del processo è nullo l'accesso è sempre garantito senza + nessun ulteriore controllo. +\item Se l'user-ID del processo corrisponde al proprietario del file allora: + \begin{itemize*} + \item se la voce \const{ACL\_USER\_OBJ} contiene il permesso richiesto, + l'accesso è consentito + \item altrimenti l'accesso è negato + \end{itemize*} +\item Se l'user-ID del processo corrisponde ad un qualunque qualificatore + presente in una voce \const{ACL\_USER} allora: + \begin{itemize*} + \item se la voce \const{ACL\_USER} corrispondente e la voce + \const{ACL\_MASK} contengono entrambe il permesso richiesto, l'accesso è + consentito + \item altrimenti l'accesso è negato + \end{itemize*} +\item Se il group-ID del processo o uno dei group-ID supplementari corrisponde + al gruppo proprietario del file o a un qualunque qualificatore di una voce + di tipo allora: + \begin{itemize*} + \item se il bit dei permessi d'accesso del gruppo è impostato, l'accesso è + consentito, + \item altrimenti l'accesso è negato + \end{itemize*} +\item Se il bit dei permessi d'accesso per tutti gli altri è impostato, + l'accesso è consentito, altrimenti l'accesso è negato. +\end{enumerate}