X-Git-Url: https://gapil.gnulinux.it/gitweb/?a=blobdiff_plain;f=filedir.tex;h=2ca508fd36d222356e6536dff9734594232127bd;hb=260bf7cea27648dc1d5a81b55b996fc4f710e507;hp=8afa6a38df23057caa5b027e7ed89799d57f6209;hpb=18c3e3a08f28307809f1846bd6063442d2bc4d3e;p=gapil.git diff --git a/filedir.tex b/filedir.tex index 8afa6a3..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}. @@ -2308,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 è: @@ -2339,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} @@ -2614,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 @@ -2954,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 @@ -2984,12 +2990,156 @@ 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 e con il collegato \texttt{libacl1-dev} - per il 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}. + 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}