From: Simone Piccardi Date: Sat, 10 May 2008 09:15:53 +0000 (+0000) Subject: Alcuni indici e materiale sulle ACL X-Git-Url: https://gapil.gnulinux.it/gitweb/?a=commitdiff_plain;h=0e21ff1145b4f9a21c582fac348c87319133f79f;p=gapil.git Alcuni indici e materiale sulle ACL --- diff --git a/filedir.tex b/filedir.tex index 8afa6a3..e0cd67d 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,6 +2308,8 @@ 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. +\itindbeg{umask} + 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 @@ -2339,6 +2341,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} @@ -2954,7 +2957,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,13 +2987,86 @@ 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, ed +uno dei problemi che si erano posti nella loro standardizzazione era appunto +quello della corrispondenza fra questi e le ACL. \itindend{Access~Control~List} diff --git a/filestd.tex b/filestd.tex index 0bb202f..32e2fd8 100644 --- a/filestd.tex +++ b/filestd.tex @@ -332,8 +332,8 @@ I nuovi file saranno creati secondo quanto visto in sez.~\ref{sec:file_ownership_management} ed avranno i permessi di accesso impostati al valore \code{S\_IRUSR|S\_IWUSR|S\_IRGRP|S\_IWGRP|S\_IROTH|S\_IWOTH} (pari a -\val{0666}) modificato secondo il valore di \acr{umask} per il processo (si -veda sez.~\ref{sec:file_perm_management}). +\val{0666}) modificato secondo il valore di \itindex{umask} \textit{umask} per +il processo (si veda sez.~\ref{sec:file_perm_management}). In caso di file aperti in lettura e scrittura occorre ricordarsi che c'è di mezzo una bufferizzazione; per questo motivo lo standard ANSI C diff --git a/fileunix.tex b/fileunix.tex index 7aeda51..b501790 100644 --- a/fileunix.tex +++ b/fileunix.tex @@ -399,10 +399,11 @@ sez.~\ref{sec:file_sharing}) ed all'inizio del file. L'argomento \param{mode} indica i permessi con cui il file viene creato; i -valori possibili sono gli stessi già visti in sez.~\ref{sec:file_perm_overview} -e possono essere specificati come OR binario delle costanti descritte in -tab.~\ref{tab:file_bit_perm}. Questi permessi sono filtrati dal valore di -\var{umask} (vedi sez.~\ref{sec:file_perm_management}) per il processo. +valori possibili sono gli stessi già visti in +sez.~\ref{sec:file_perm_overview} e possono essere specificati come OR binario +delle costanti descritte in tab.~\ref{tab:file_bit_perm}. Questi permessi sono +filtrati dal valore di \itindex{umask} \textit{umask} (vedi +sez.~\ref{sec:file_perm_management}) per il processo. La funzione prevede diverse opzioni, che vengono specificate usando vari bit dell'argomento \param{flags}. Alcuni di questi bit vanno anche a costituire diff --git a/ipc.tex b/ipc.tex index e17fe6d..ff728dc 100644 --- a/ipc.tex +++ b/ipc.tex @@ -978,7 +978,7 @@ solo se tutti i controlli elencati falliscono l'accesso a differenza di quanto avviene per i permessi dei file, fallire in uno dei passi elencati non comporta il fallimento dell'accesso. Un'ulteriore differenza rispetto a quanto avviene per i file è che per gli oggetti di IPC -il valore di \var{umask} (si ricordi quanto esposto in +il valore di \itindex{umask} \textit{umask} (si ricordi quanto esposto in sez.~\ref{sec:file_perm_management}) non ha alcun significato. @@ -4041,9 +4041,9 @@ accesso. Questo significa che un nuovo semaforo viene sempre creato con l'user-ID ed il group-ID effettivo del processo chiamante, e che i permessi indicati con -\param{mode} vengono filtrati dal valore della \textit{umask} del processo. -Inoltre per poter aprire un semaforo è necessario avere su di esso sia il -permesso di lettura che quello di scrittura. +\param{mode} vengono filtrati dal valore della \itindex{umask} \textit{umask} +del processo. Inoltre per poter aprire un semaforo è necessario avere su di +esso sia il permesso di lettura che quello di scrittura. Una volta che si sia ottenuto l'indirizzo di un semaforo, sarà possibile utilizzarlo; se si ricorda quanto detto all'inizio di diff --git a/prochand.tex b/prochand.tex index 3810e41..76bd1bc 100644 --- a/prochand.tex +++ b/prochand.tex @@ -1442,7 +1442,7 @@ la lista completa \item il tempo restante ad un allarme (vedi sez.~\ref{sec:sig_alarm_abort}); \item la directory radice e la directory di lavoro corrente (vedi sez.~\ref{sec:file_work_dir}); -\item la maschera di creazione dei file (\var{umask}, vedi +\item la maschera di creazione dei file \itindex{umask} (\textit{umask}, vedi sez.~\ref{sec:file_perm_management}) ed i \textit{lock} sui file (vedi sez.~\ref{sec:file_locking}); \item i segnali sospesi (\textit{pending}) e la maschera dei segnali (si veda diff --git a/session.tex b/session.tex index 5c62d91..78b60ec 100644 --- a/session.tex +++ b/session.tex @@ -645,9 +645,9 @@ occorrer il programma), per evitare che la directory da cui si è lanciato il processo resti in uso e non sia possibile rimuoverla o smontare il filesystem che la contiene. -\item Impostare la maschera dei permessi (di solito con \code{umask(0)}) in - modo da non essere dipendenti dal valore ereditato da chi ha lanciato - originariamente il processo. +\item Impostare la \itindex{umask} maschera dei permessi (di solito con + \code{umask(0)}) in modo da non essere dipendenti dal valore ereditato da + chi ha lanciato originariamente il processo. \item Chiudere tutti i file aperti che non servono più (in generale tutti); in particolare vanno chiusi i file standard che di norma sono ancora associati al terminale (un'altra opzione è quella di redirigerli verso