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
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}.
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}
\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}).}
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
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}
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:
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 è:
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}
'70, quando le risorse di calcolo e di spazio disco erano minime. Con il venir
meno di queste restrizioni è incominciata ad emergere l'esigenza di poter
associare ai file delle ulteriori informazioni astratte (quelli che vengono
-chiamati i \textsl{meta-dati}) che però non potevano trovar spazio nei dati
+chiamati i \textsl{meta-dati}) che però non potevano trovare spazio nei dati
classici mantenuti negli inode.
Per risolvere questo problema alcuni sistemi unix-like (e fra questi anche
gli \textit{Extended Attributes} (anche se su Solaris hanno lo stesso nome),
che sono un meccanismo molto più semplice, che pur essendo limitato (potendo
contenere solo una quantità limitata di informazione) hanno il grande
-vantaggio di essere molto più semplici da realizzare e più
+vantaggio di essere molto più semplici da realizzare, più
efficienti,\footnote{cosa molto importante, specie per le applicazioni che
richiedono una gran numero di accessi, come le ACL.} e di garantire
l'atomicità di tutte le operazioni.
\begin{table}[htb]
\centering
\footnotesize
- \begin{tabular}{|c|p{8cm}|}
+ \begin{tabular}{|c|p{10cm}|}
\hline
\textbf{Nome} & \textbf{Descrizione} \\
\hline
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
uno standard, dato però che una parte della documentazione prodotta era di
alta qualità venne deciso di rilasciare al pubblico la diciassettesima bozza
del documento, quella che va sotto il nome di \textit{POSIX 1003.1e Draft 17},
-che è divenuta la base sulla quale si definiscono quelle che vanno sotto il
-nome di \textit{Posix ACL}.
+che è divenuta la base sulla quale si definiscono le cosiddette \textit{Posix
+ ACL}.
A differenza di altri sistemi (ad esempio FreeBSD) nel caso di Linux si è
scelto di realizzare le ACL attraverso l'uso degli
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 per questo 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 ciascuna di queste voci dovrà fare riferimento ad un utente o ad un
+gruppo diverso, e non corrispondenti a quelli proprietari del file. 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
+una ACL di tipo \const{ACL\_MASK} è di particolare utilità quando essa
+associata ad una \textit{default ACL} su una directory, in quanto i permessi
+così specificati verranno ereditati da tutti i file creati nella stessa
+directory. Si ottiene così 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 permessi 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ò essere 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 soltanto
+se non è presente una voce di tipo \const{ACL\_MASK}, se invece questa è
+presente verranno tolti dai permessi di \const{ACL\_GROUP\_OBJ} tutti quelli
+non presenti in \const{ACL\_MASK}.\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 \textit{default ACL} sulla directory che contiene quel file.
+Se questa non c'è valgono le regole usuali 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 anche
+su una ACL di accesso assegnata automaticamente al nuovo file, che contiene
+soltanto le tre corrispondenti 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à automaticamente la sua ACL di accesso, a meno di non
+aver indicato, nelle funzioni di creazione che lo consentono, uno specifico
+valore per i permessi ordinari;\footnote{tutte le funzioni citate in
+ precedenza supportano un argomento \var{mode} che indichi un insieme di
+ permessi iniziale.} in tal caso saranno eliminati dalle voci corrispondenti
+nella ACL tutti quelli non presenti in tale indicazione.
+
+Dato che questa è la ragione che ha portato alla loro creazione, la pricipale
+modifica introdotta con la presenza della ACL è quella alle regole del
+controllo di accesso ai file illustrate in sez.~\ref{sec:file_perm_overview}.
+Come nel caso ordinario per il controllo vengono sempre utilizzati gli
+identificatori del gruppo \textit{effective} del processo, ma in presenza di
+ACL 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 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 allora:
+ \begin{itemize*}
+ \item se la voce \const{ACL\_GROUP\_OBJ} e una eventuale voce
+ \const{ACL\_MASK} (se non vi sono voci di tipo \const{ACL\_GROUP} questa
+ può non essere presente) 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 ad un qualunque qualificatore presente in una voce
+ \const{ACL\_GROUP} allora:
+ \begin{itemize*}
+ \item se la voce \const{ACL\_GROUP} corrispondente e la voce
+ \const{ACL\_MASK} contengono entrambe il permesso richiesto, l'accesso è
+ consentito;
+ \item altrimenti l'accesso è negato.
+ \end{itemize*}
+\item Se la voce \const{ACL\_USER\_OBJ} contiene il permesso richiesto,
+ l'accesso è consentito, altrimenti l'accesso è negato.
+\end{enumerate*}
+
+I passi di controllo vengono eseguiti esattamente in questa sequenza, e la
+decisione viene presa non appena viene trovata una corrispondenza con gli
+identificatori del processo. Questo significa che i permessi presenti in una
+voce di tipo \const{ACL\_USER} hanno la precedenza sui permessi ordinari
+associati al gruppo proprietario del file (vale a dire su
+\const{ACL\_GROUP\_OBJ}).
+
+Per la gestione delle ACL lo standard \textit{POSIX 1003.1e Draft 17} ha
+previsto delle apposite funzioni ed tutta una serie di tipi di dati
+dedicati;\footnote{fino a definire un tipo di dato e delle costanti apposite
+ per identificare i permessi standard di lettura, scrittura ed esecuzione.}
+tutte le operazioni devono essere effettuate attraverso tramite questi tipi di
+dati, che incapsulano tutte le informazioni contenute nelle ACL. La prima di
+queste funzioni che prendiamo in esame è \funcd{acl\_init}, il cui prototipo
+è:
+\begin{functions}
+ \headdecl{sys/types.h}
+ \headdecl{sys/acl.h}
+
+ \funcdecl{acl\_t acl\_init(int count)}
+
+ Inizializza un'area di lavoro per una ACL di \param{count} voci.
+
+ \bodydesc{La funzione restituisce un puntatore all'area di lavoro in caso di
+ successo e \const{NULL} in caso di errore, nel qual caso \var{errno}
+ assumerà uno dei valori:
+ \begin{errlist}
+ \item[\errcode{EINVAL}] il valore di \param{count} è negativo.
+ \item[\errcode{ENOMEM}] non c'è sufficiente memoria disponibile.
+ \end{errlist}
+}
+\end{functions}
+
+La funzione alloca ed inizializza un'area di memoria che verrà usata per
+mantenere i dati di una ACL contenente fino ad un massimo di \const{count}
+voci. La funzione ritorna un valore di tipo \type{acl\_t}, da usare in tutte
+le altre funzioni che operano sulla ACL. La funzione si limita alla
+allocazione iniziale e non inserisce nessun valore nella ACL che resta vuota.
+Si tenga presente che pur essendo \type{acl\_t} un tipo opaco che identifica
+``\textsl{l'oggetto}'' ACL, il valore restituito dalla funzione non è altro
+che un puntatore all'area di memoria allocata per i dati richiesti; pertanto
+in caso di fallimento verrà restituito un puntatore nullo e si dovrà
+confrontare il valore di ritorno della funzione con ``\code{(acl\_t) NULL}''.
+
+Una volta che si siano completate le operazioni sui dati di una ACL la memoria
+allocata dovrà essere liberata esplicitamente attraverso una chiamata alla
+funzione \funcd{acl\_free}, il cui protipo è:
+\begin{functions}
+ \headdecl{sys/types.h}
+ \headdecl{sys/acl.h}
+
+ \funcdecl{int acl\_free(void * obj\_p)}
+
+ Disalloca la memoria riservata per i dati di una ACL.
+
+ \bodydesc{La funzione restituisce 0 in caso di successo e $-1$ se
+ \param{obj\_p} non è un puntatore valido, nel qual caso \var{errno}
+ assumerà il valore \errcode{EINVAL}
+}
+\end{functions}
+
+Si noti come la funzione richieda come argomento un puntatore di tipo
+``\ctyp{void *}'', essa infatti può essere usata non solo per liberare la
+memoria allocata per i dati di una ACL, ma anche per quella usata per creare
+le stringhe di descrizione testuale delle ACL o per ottenere i valori dei
+qualificatori di una voce; pertanto a seconda dei casi occorrerà eseguire un
+\textit{cast} a ``\ctyp{void *}'' del tipo di dato di cui si vuole eseguire la
+disallocazione. Si tenga presente poi che oltre a \func{acl\_init} esistono
+molte altre funzioni che possono allocare memoria per i dati delle ACL, è
+pertanto opportuno tenere traccia di tutte queste funzioni perché alla fine
+delle operazioni tutta la memoria allocata dovrà essere liberata con
+\func{acl\_free}.
+
+Una volta che si abbiano a disposizione i dati di una ACL tramite il
+riferimento ad oggetto di tipo \type{acl\_t} questi potranno essere copiati
+con la funzione \funcd{acl\_dup}, il cui prototipo è:
+\begin{functions}
+ \headdecl{sys/types.h}
+ \headdecl{sys/acl.h}
+
+ \funcdecl{acl\_t acl\_dup(acl\_t acl)}
+
+ Crea una copia della ACL \param{acl}.
+
+ \bodydesc{La funzione restituisce un oggetto di tipo \type{acl\_t} in caso
+ di successo e \code{(acl\_t)NULL} in caso di errore, nel qual caso
+ \var{errno} assumerà uno dei valori:
+ \begin{errlist}
+ \item[\errcode{EINVAL}] l'argomento \param{acl} non è un puntatore valido
+ per una ACL.
+ \item[\errcode{ENOMEM}] non c'è sufficiente memoria disponibile per eseguire
+ la copia.
+ \end{errlist}
+}
+\end{functions}
+
+La funzione crea una copia dei dati della ACL indicata tramite l'argomento
+\param{acl}, allocando autonomamente tutto spazio necessario alla copia e
+restituendo un secondo oggetto di tipo \type{acl\_t} come riferimento a
+quest'ultima. Valgono per questo le stesse considerazioni fatte per il valore
+di ritorno di \func{acl\_init}, ed in particolare il fatto che occorrerà
+prevedere una ulteriore chiamata esplicita a \func{acl\_free} per liberare la
+memoria occupata dalla copia.
+
+Se si deve creare una ACL manualmente l'uso di \func{acl\_init} è scomodo,
+dato che la funzione restituisce una ACL vuota, una alternativa allora è usare
+\funcd{acl\_from\_mode} che consente di creare una ACL a partire da un valore
+di permessi ordinari, il prototipo della funzione è:
+\begin{functions}
+ \headdecl{sys/types.h}
+ \headdecl{sys/acl.h}
+
+ \funcdecl{acl\_t acl\_from\_mode(mode\_t mode)}
+
+ Crea una ACL inizializzata con i permessi di \param{mode}.
+
+ \bodydesc{La funzione restituisce un oggetto di tipo \type{acl\_t} in caso
+ di successo e \code{(acl\_t)NULL} in caso di errore, nel qual caso
+ \var{errno} assumerà il valore \errval{ENOMEM}.
+
+}
+\end{functions}
+
+La funzione restituisce una ACL inizializzata con le tre voci obbligatorie
+\const{ACL\_USER\_OBJ}, \const{ACL\_GROUP\_OBJ} e \const{ACL\_OTHER} già
+impostate secondo la corrispondenza ai valori dei permessi ordinari indicati
+dalla maschera passata nell'argomento \param{mode}. Questa funzione è una
+estensione usata dalle ACL di Linux e non è portabile, ma consente di
+semplificare l'inizializzazione in maniera molto comoda.
+
+Altre due funzioni che consentono di creare una ACL già inizializzata sono
+\funcd{acl\_get\_fd} e \funcd{acl\_get\_file}, che però sono per lo più
+utilizzate per leggere la ACL corrente di un file; i rispettivi prototipi
+sono:
+\begin{functions}
+ \headdecl{sys/types.h}
+ \headdecl{sys/acl.h}
+
+ \funcdecl{acl\_t acl\_get\_file(const char *path\_p, acl\_type\_t type)}
+ \funcdecl{acl\_t acl\_get\_fd(int fd)}
+
+ Ottiene i dati delle ACL di un file.
+
+ \bodydesc{La funzione restituisce un oggetto di tipo \type{acl\_t} in caso
+ di successo e \code{(acl\_t)NULL} in caso di errore, nel qual caso
+ \var{errno} assumerà uno dei valori:
+ \begin{errlist}
+ \item[\errcode{ENOMEM}] non c'è memoria sufficiente per allocare i dati.
+ \item[\errcode{ENOTSUP}] il filesystem cui fa riferimento il file non
+ supporta le ACL.
+ \end{errlist}
+ ed inoltre \errval{EBADF} per \func{acl\_get\_fd}, ed \errval{EINVAL} per
+ valori scorretti di \param{type} e tutti i possibili errori per l'accesso ad
+ un file per \func{acl\_get\_file}.
+}
+\end{functions}
+
+Le due funzioni ritornano, con un oggetto di tipo \type{acl\_t}, il valore
+della ACL correntemente associata ad un file, che può essere identificato
+tramite un file descriptor usando \func{acl\_get\_fd} o con un pathname usando
+\func{acl\_get\_file}. Nel caso di quest'ultima funzione, che può richiedere
+anche la ACL relativa ad una directory, il secondo argomento \param{type}
+consente di specificare se si vuole ottenere la ACL di default o quella di
+accesso. Questo argomento deve essere di tipo \type{acl\_type\_t} e può
+assumere solo i due valori riportati in tab.~\ref{tab:acl_type}.
+\begin{table}[htb]
+ \centering
+ \footnotesize
+ \begin{tabular}{|l|l|}
+ \hline
+ \textbf{Tipo} & \textbf{Descrizione} \\
+ \hline
+ \hline
+ \const{ACL\_TYPE\_ACCESS} & indica una ACL di accesso.\\
+ \const{ACL\_TYPE\_DEFAULT}& indica una ACL di default.\\
+ \hline
+ \end{tabular}
+ \caption{Le costanti che identificano il tipo di ACL.}
+ \label{tab:acl_type}
+\end{table}
+Si tenga presente che nel caso di \func{acl\_get\_file} occorrerà che il
+processo chiamante abbia privilegi di accesso sufficenti a poter leggere gli
+attributi estesi dei file (come illustrati in sez.~\ref{sec:file_xattr});
+inoltre una ACL di tipo \const{ACL\_TYPE\_DEFAULT} potrà essere richiesta
+soltanto per una directory, e verrà restituita solo se presente, altrimenti
+verrà restituita una ACL vuota.
+
+Infine si potrà creare una ACL direttamente dalla sua rappresentazione
+testuale con la funzione \funcd{acl\_from\_text}, il cui prototipo è:
+\begin{functions}
+ \headdecl{sys/types.h}
+ \headdecl{sys/acl.h}
+
+ \funcdecl{acl\_t acl\_from\_text(const char *buf\_p)}
+
+ Crea una ACL a partire dalla sua rappresentazione testuale.
+
+ \bodydesc{La funzione restituisce un oggetto di tipo \type{acl\_t} in caso
+ di successo e \code{(acl\_t)NULL} in caso di errore, nel qual caso
+ \var{errno} assumerà uno dei valori:
+ \begin{errlist}
+ \item[\errcode{ENOMEM}] non c'è memoria sufficiente per allocare i dati.
+ \item[\errcode{EINVAL}] la rappresentazione testuale all'indirizzo
+ \param{buf\_p} non è valida.
+ \end{errlist}
+
+}
+\end{functions}
+La funzione prende come argomento il puntatore ad un buffer dove si è inserita
+la rappresentazione testuale della ACL che si vuole creare, la memoria
+necessaria viene automaticamente allocata ed in caso di successo viene
+restituito come valore di ritorno un oggetto di tipo \type{acl\_t} con il
+contenuto della stessa, che come per le precedenti funzioni, dovrà essere
+disallocato esplicitamente al termine del suo utilizzo.
+
+La rappresentazione testuale di una ACL è quella usata anche dai comandi
+ordinari per la gestione delle ACL (\texttt{getfacl} e \texttt{setfacl}), che
+prevede due diverse forme, estesa e breve, entrambe supportate da
+\func{acl\_from\_text}. La forma estesa prevede che sia specificata una voce
+per riga, nella forma:
+\begin{Verbatim}
+ tipo:qualificatore:permessi
+\end{Verbatim}
+dove il tipo può essere uno fra \texttt{user}, \texttt{group}, \texttt{other}
+e \texttt{mask}, il qualificatore è presente solo per \texttt{user},
+\texttt{group} e indica l'utente o il gruppo a cui la voce si riferisce e i
+permessi sono espressi con una tripletta di lettere analoga a quella usata per
+i permessi dei file.
+
+Va precisato che i due tipi \texttt{user}, \texttt{group} sono usati
+rispettivamente per indicare delle voci relative ad utenti e
+gruppi,\footnote{cioè per voci di tipo \const{ACL\_USER\_OBJ} e
+ \const{ACL\_USER} per \texttt{user} e \const{ACL\_GROUP\_OBJ} e
+ \const{ACL\_GROUP} per \texttt{group}.} applicate sia a quelli proprietari
+del file che a quelli generici (quelle dei proprietari si riconoscono per
+l'assenza di un qualificatore).
\itindend{Access~Control~List}
-% TODO trattare le ACL, la documentazione di sistema è nei pacchetti
+% TODO trattare le ACL, la documentazione di sistema è nei pacchetti
% libacl1-dev e acl
% vedi anche http://www.suse.de/~agruen/acl/linux-acls/online/
\subsection{La funzione \func{chroot}}
\label{sec:file_chroot}
-% TODO intrudurre nuova sezione sulle funzionalità di sicurezza avanzate, con
+% TODO introdurre nuova sezione sulle funzionalità di sicurezza avanzate, con
% dentro chroot SELinux e AppArmor ???
Benché non abbia niente a che fare con permessi, utenti e gruppi, la funzione
% LocalWords: IRWXO ext reiser capability FSETID mask capabilities chroot jail
% LocalWords: FTP Di filter reiserfs Attributes Solaris Posix FreeBSD libacl
% LocalWords: XFS SELinux namespace attribute security trusted Draft Modules
-% LocalWords: attributes mime ADMIN FOWNER libattr lattr getxattr lgetxattr
+% LocalWords: attributes mime ADMIN FOWNER libattr lattr getxattr lgetxattr of
% LocalWords: fgetxattr attr ssize ENOATTR ENOTSUP NUL setxattr lsetxattr list
-% LocalWords: fsetxattr flags XATTR REPLACE listxattr llistxattr flistxattr
-% LocalWords: removexattr lremovexattr fremovexattr attributename lacl
+% LocalWords: fsetxattr flags XATTR REPLACE listxattr llistxattr flistxattr by
+% LocalWords: removexattr lremovexattr fremovexattr attributename lacl acl
%%% Local Variables:
%%% mode: latex
%%% TeX-master: "gapil"
%%% End:
+% LocalWords: OBJ
projects / gapil.git / blobdiff