sez.~\ref{sec:proc_race_cond}).
Le \acr{glibc} provvedono varie funzioni per generare nomi di file temporanei,
-di cui si abbia certezza di unicità (al momento della generazione); la prima
-di queste funzioni è \funcd{tmpnam} il cui prototipo è:
+di cui si abbia certezza di unicità al momento della generazione; storicamente
+la prima di queste funzioni create a questo scopo era
+\funcd{tmpnam},\footnote{la funzione è stata deprecata nella revisione
+ POSIX.1-2008 dello standard POSIX.} il cui prototipo è:
\begin{prototype}{stdio.h}{char *tmpnam(char *string)}
- Restituisce il puntatore ad una stringa contente un nome di file valido e
- non esistente al momento dell'invocazione.
-
+ Genera un nome univoco per un file temporaneo.
+
\bodydesc{La funzione ritorna il puntatore alla stringa con il nome o
\val{NULL} in caso di fallimento. Non sono definiti errori.}
\end{prototype}
-\noindent se si è passato un puntatore \param{string} non nullo questo deve
-essere di dimensione \const{L\_tmpnam} (costante definita in \file{stdio.h},
-come \const{P\_tmpdir} e \const{TMP\_MAX}) ed il nome generato vi verrà
-copiato automaticamente; altrimenti il nome sarà generato in un buffer statico
-interno che verrà sovrascritto ad una chiamata successiva. Successive
+
+La funzione restituisce il puntatore ad una stringa contente un nome di file
+valido e non esistente al momento dell'invocazione; se si è passato come
+argomento \param{string} un puntatore non nullo ad un buffer di caratteri
+questo deve essere di dimensione \const{L\_tmpnam} ed il nome generato vi
+verrà copiato automaticamente; altrimenti il nome sarà generato in un buffer
+statico interno che verrà sovrascritto ad una chiamata successiva. Successive
invocazioni della funzione continueranno a restituire nomi unici fino ad un
-massimo di \const{TMP\_MAX} volte. Al nome viene automaticamente aggiunto come
-prefisso la directory specificata da \const{P\_tmpdir}.
+massimo di \const{TMP\_MAX} volte, limite oltre il quale il comportamento è
+indefinito. Al nome viene automaticamente aggiunto come prefisso la directory
+specificata dalla costante \const{P\_tmpdir}.\footnote{le costanti
+ \const{L\_tmpnam}, \const{P\_tmpdir} e \const{TMP\_MAX} sono definite in
+ \file{stdio.h}.}
Di questa funzione esiste una versione \index{funzioni!rientranti} rientrante,
\func{tmpnam\_r}, che non fa nulla quando si passa \val{NULL} come argomento.
Una funzione simile, \funcd{tempnam}, permette di specificare un prefisso per
il file esplicitamente, il suo prototipo è:
\begin{prototype}{stdio.h}{char *tempnam(const char *dir, const char *pfx)}
- Restituisce il puntatore ad una stringa contente un nome di file valido e
- non esistente al momento dell'invocazione.
+ Genera un nome univoco per un file temporaneo.
\bodydesc{La funzione ritorna il puntatore alla stringa con il nome o
\val{NULL} in caso di fallimento, \var{errno} viene impostata a
per cui è sempre \index{funzioni!rientranti} rientrante, occorre però
ricordarsi di disallocare con \code{free} il puntatore che restituisce.
L'argomento \param{pfx} specifica un prefisso di massimo 5 caratteri per il
-nome provvisorio. La funzione assegna come directory per il file temporaneo
-(verificando che esista e sia accessibili), la prima valida delle seguenti:
-\begin{itemize}
+nome provvisorio. La funzione assegna come directory per il file temporaneo,
+verificando che esista e sia accessibile, la prima valida fra le seguenti:
+\begin{itemize*}
\item La variabile di ambiente \const{TMPDIR} (non ha effetto se non è
definita o se il programma chiamante è \itindex{suid~bit} \acr{suid} o
\itindex{sgid~bit} \acr{sgid}, vedi sez.~\ref{sec:file_special_perm}).
\item il valore dell'argomento \param{dir} (se diverso da \val{NULL}).
\item Il valore della costante \const{P\_tmpdir}.
\item la directory \file{/tmp}.
-\end{itemize}
+\end{itemize*}
In ogni caso, anche se la generazione del nome è casuale, ed è molto difficile
ottenere un nome duplicato, nulla assicura che un altro processo non possa
Per evitare di dovere effettuare a mano tutti questi controlli, lo standard
POSIX definisce la funzione \funcd{tmpfile}, che permette di ottenere in
maniera sicura l'accesso ad un file temporaneo, il suo prototipo è:
-\begin{prototype}{stdio.h}{FILE *tmpfile (void)}
+\begin{prototype}{stdio.h}{FILE *tmpfile(void)}
Restituisce un file temporaneo aperto in lettura/scrittura.
\bodydesc{La funzione ritorna il puntatore allo stream associato al file
unico. La prima delle due è analoga a \func{tmpnam} e genera un nome casuale,
il suo prototipo è:
\begin{prototype}{stlib.h}{char *mktemp(char *template)}
- Genera un filename univoco sostituendo le \code{XXXXXX} finali di
- \param{template}.
+ Genera un nome univoco per un file temporaneo.
\bodydesc{La funzione ritorna il puntatore \param{template} in caso di
successo e \val{NULL} in caso di errore, nel qual caso \var{errno}
\item[\errcode{EINVAL}] \param{template} non termina con \code{XXXXXX}.
\end{errlist}}
\end{prototype}
-\noindent dato che \param{template} deve poter essere modificata dalla
+
+La funzionne genera un nome univoco sostituendo le \code{XXXXXX} finali di
+\param{template}; dato che \param{template} deve poter essere modificata dalla
funzione non si può usare una stringa costante. Tutte le avvertenze riguardo
alle possibili \itindex{race~condition} \textit{race condition} date per
\func{tmpnam} continuano a valere; inoltre in alcune vecchie implementazioni
usata.
La seconda funzione, \funcd{mkstemp} è sostanzialmente equivalente a
-\func{tmpfile}, ma restituisce un file descriptor invece di uno stream; il suo
+\func{tmpfile}, ma restituisce un file descriptor invece di un nome; il suo
prototipo è:
\begin{prototype}{stlib.h}{int mkstemp(char *template)}
- Genera un file temporaneo con un nome ottenuto sostituendo le \code{XXXXXX}
- finali di \param{template}.
+ Genera un file temporaneo.
- \bodydesc{La funzione ritorna il file descriptor in caso successo e
+ \bodydesc{La funzione ritorna il file descriptor in caso di successo e
-1 in caso di errore, nel qual caso \var{errno} assumerà i valori:
\begin{errlist}
\item[\errcode{EINVAL}] \param{template} non termina con \code{XXXXXX}.
contenuto di \param{template} è indefinito.
\end{errlist}}
\end{prototype}
-\noindent come per \func{mktemp} anche in questo caso \param{template} non può
-essere una stringa costante. La funzione apre un file in lettura/scrittura con
-la funzione \func{open}, usando l'opzione \const{O\_EXCL} (si veda
+
+Come per \func{mktemp} anche in questo caso \param{template} non può essere
+una stringa costante. La funzione apre un file in lettura/scrittura con la
+funzione \func{open}, usando l'opzione \const{O\_EXCL} (si veda
sez.~\ref{sec:file_open}), in questo modo al ritorno della funzione si ha la
-certezza di essere i soli utenti del file. I permessi sono impostati al valore
-\code{0600}\footnote{questo è vero a partire dalle \acr{glibc} 2.0.7, le
- versioni precedenti delle \acr{glibc} e le vecchie \acr{libc5} e \acr{libc4}
- usavano il valore \code{0666} che permetteva a chiunque di leggere i
- contenuti del file.} (si veda sez.~\ref{sec:file_perm_overview}).
-
-In OpenBSD è stata introdotta un'altra funzione\footnote{introdotta anche in
- Linux a partire dalle \acr{glibc} 2.1.91.} simile alle precedenti,
-\funcd{mkdtemp}, che crea una directory temporanea; il suo prototipo è:
+certezza di essere stati i creatori del file, i cui permessi (si veda
+sez.~\ref{sec:file_perm_overview}) sono impostati al valore \code{0600}
+(lettura e scrittura solo per il proprietario).\footnote{questo è vero a
+ partire dalle \acr{glibc} 2.0.7, le versioni precedenti delle \acr{glibc} e
+ le vecchie \acr{libc5} e \acr{libc4} usavano il valore \code{0666} che
+ permetteva a chiunque di leggere e scrivere i contenuti del file.} Di
+questa funzione esiste una variante \funcd{mkostemp}, introdotta
+specificamente dalla \acr{glibc},\footnote{la funzione è stata introdotta
+ nella versione 2.7 delle librerie e richiede che sia definita la macro
+ \const{\_GNU\_SOURCE}.} il cui prototipo è:
+\begin{prototype}{stlib.h}{int mkostemp(char *template, int flags)}
+ Genera un file temporaneo.
+
+ \bodydesc{La funzione ritorna il file descriptor in caso di successo e
+ -1 in caso di errore, con gli stessi errori di \func{mkstemp}.}
+\end{prototype}
+\noindent la cui sola differenza è la presenza dell'ulteriore argomento
+\var{flags} che consente di specificare i flag da passare ad \func{open}
+nell'apertura del file.
+
+
+In OpenBSD è stata introdotta un'altra funzione simile alle precedenti,
+\funcd{mkdtemp}, che crea invece una directory temporanea;\footnote{la
+ funzione è stata introdotta nelle \acr{glibc} a partire dalla versione
+ 2.1.91 ed inserita nello standard POSIX.1-2008.} il suo prototipo è:
\begin{prototype}{stlib.h}{char *mkdtemp(char *template)}
- Genera una directory temporaneo il cui nome è ottenuto sostituendo le
- \code{XXXXXX} finali di \param{template}.
+ Genera una directory temporanea.
\bodydesc{La funzione ritorna il puntatore al nome della directory in caso
successo e \val{NULL} in caso di errore, nel qual caso \var{errno}
\end{errlist}
più gli altri eventuali codici di errore di \func{mkdir}.}
\end{prototype}
-\noindent la directory è creata con permessi \code{0700} (al solito si veda
-cap.~\ref{cha:file_unix_interface} per i dettagli); dato che la creazione
-della directory è sempre esclusiva i precedenti problemi di
+
+La funzione genera una directory il cui nome è ottenuto sostituendo le
+\code{XXXXXX} finali di \param{template} con permessi \code{0700} (al solito
+si veda cap.~\ref{cha:file_unix_interface} per i dettagli); dato che la
+creazione della directory è sempre esclusiva i precedenti problemi di
\itindex{race~condition} \textit{race condition} non si pongono.
\label{sec:file_stat}
La lettura delle informazioni relative ai file è fatta attraverso la famiglia
-delle funzioni \func{stat} (\funcd{stat}, \funcd{fstat} e \funcd{lstat});
-questa è la funzione che ad esempio usa il comando \cmd{ls} per poter ottenere
-e mostrare tutti i dati relativi ad un file. I prototipi di queste funzioni
-sono i seguenti:
+delle funzioni \func{stat} che sono quelle che usa il comando \cmd{ls} per
+poter ottenere e mostrare tutti i dati relativi ad un file; ne fanno parte le
+funzioni \funcd{stat}, \funcd{fstat} e \funcd{lstat}, i cui prototipi sono:
\begin{functions}
\headdecl{sys/types.h}
\headdecl{sys/stat.h}
\headdecl{unistd.h}
- \funcdecl{int stat(const char *file\_name, struct stat *buf)} Legge le
- informazione del file specificato da \param{file\_name} e le inserisce in
- \param{buf}.
-
- \funcdecl{int lstat(const char *file\_name, struct stat *buf)} Identica a
- \func{stat} eccetto che se il \param{file\_name} è un link simbolico vengono
- lette le informazioni relative ad esso e non al file a cui fa riferimento.
-
- \funcdecl{int fstat(int filedes, struct stat *buf)} Identica a \func{stat}
- eccetto che si usa con un file aperto, specificato tramite il suo file
- descriptor \param{filedes}.
-
+ \funcdecl{int stat(const char *file\_name, struct stat *buf)}
+ \funcdecl{int lstat(const char *file\_name, struct stat *buf)}
+ \funcdecl{int fstat(int filedes, struct stat *buf)}
+ Legge le informazioni di un file.
+
\bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 per un
errore, nel qual caso \var{errno} assumerà uno dei valori: \errval{EBADF},
\errval{ENOENT}, \errval{ENOTDIR}, \errval{ELOOP}, \errval{EFAULT},
\errval{EACCES}, \errval{ENOMEM}, \errval{ENAMETOOLONG}.}
\end{functions}
-\noindent il loro comportamento è identico, solo che operano rispettivamente
-su un file, su un link simbolico e su un file descriptor.
+
+La funzione \func{stat} legge le informazion del file il cui pathname è
+specificato dalla stringa puntata da \param{file\_name} e le inserisce nel
+buffer puntato dall'argomento \param{buf}; la funzione \func{lstat} è identica
+a \func{stat} eccetto che se \param{file\_name} è un link simbolico vengono
+lette le informazioni relative ad esso e non al file a cui fa
+riferimento. Infine \func{fstat} esegue la stessa operazione su un file già
+aperto, specificato tramite il suo file descriptor \param{filedes}.
La struttura \struct{stat} usata da queste funzioni è definita nell'header
\file{sys/stat.h} e in generale dipende dall'implementazione; la versione
detto che corrisponda all'occupazione dello spazio su disco per via della
possibile esistenza dei cosiddetti \index{file!\textit{hole}} \textit{holes}
(letteralmente \textsl{buchi}) che si formano tutte le volte che si va a
-scrivere su un \itindex{sparse~file} file dopo aver eseguito una \func{lseek}
-(tratteremo in dettaglio l'argomento in sez.~\ref{sec:file_lseek}) oltre la
-sua fine.
+scrivere su un \itindex{sparse~file} file dopo aver eseguito uno spostamento
+oltre la sua fine (tratteremo in dettaglio l'argomento in
+sez.~\ref{sec:file_lseek}).
In questo caso si avranno risultati differenti a seconda del modo in cui si
calcola la lunghezza del file, ad esempio il comando \cmd{du}, (che riporta il
dimensione si possono usare le due funzioni \funcd{truncate} e
\funcd{ftruncate}, i cui prototipi sono:
\begin{functions}
- \headdecl{unistd.h} \funcdecl{int truncate(const char *file\_name, off\_t
- length)} Fa si che la dimensione del file \param{file\_name} sia troncata
- ad un valore massimo specificato da \param{length}.
-
- \funcdecl{int ftruncate(int fd, off\_t length))} Identica a \func{truncate}
- eccetto che si usa con un file aperto, specificato tramite il suo file
- descriptor \param{fd}.
-
+ \headdecl{unistd.h}
+
+ \funcdecl{int truncate(const char *file\_name, off\_t length)}
+
+ \funcdecl{int ftruncate(int fd, off\_t length))}
+
+ Troncano un file alla lunghezza \param{length}.
+
\bodydesc{Le funzioni restituiscono zero in caso di successo e -1 per un
errore, nel qual caso \var{errno} viene impostata opportunamente; per
\func{ftruncate} si hanno i valori:
\errval{EROFS}, \errval{EIO}, \errval{EFAULT}, \errval{ELOOP}.}
\end{functions}
-Se il file è più lungo della lunghezza specificata i dati in eccesso saranno
-perduti; il comportamento in caso di lunghezza inferiore non è specificato e
-dipende dall'implementazione: il file può essere lasciato invariato o esteso
-fino alla lunghezza scelta; nel caso di Linux viene esteso con la creazione di
-un \index{file!\textit{hole}} \textsl{buco} nel \itindex{sparse~file} file e
-ad una lettura si otterranno degli zeri.
+Emtrambe le funzioni fan sì che la dimensione del file sia troncata ad un
+valore massimo specificato da \param{length}, e si distinguono solo per il
+fatto che il file viene indicato con il pathame \param{file\_name} per
+\func{truncate} e con il file descriptor \param{fd} per \funcd{ftruncate}; se
+il file è più lungo della lunghezza specificata i dati in eccesso saranno
+perduti.
+
+Il comportamento in caso di lunghezza inferiore non è specificato e dipende
+dall'implementazione: il file può essere lasciato invariato o esteso fino alla
+lunghezza scelta; nel caso di Linux viene esteso con la creazione di un
+\index{file!\textit{hole}} \textsl{buco} nel \itindex{sparse~file} file e ad
+una lettura si otterranno degli zeri; si tenga presente però che questo
+comportamento è supportato solo per filesystem nativi, ad esempio su un
+filesystem non nativo come il VFAT di windows questo non è possibile.
\subsection{I tempi dei file}
\label{sec:file_file_times}
-Il sistema mantiene per ciascun file tre tempi. Questi sono registrati
+Il sistema mantiene per ciascun file tre tempi, questi sono registrati
\itindex{inode} nell'\textit{inode} insieme agli altri attributi del file e
possono essere letti tramite la funzione \func{stat}, che li restituisce
-attraverso tre campi della struttura \struct{stat} di
+attraverso tre specifici campi della struttura \struct{stat} di
fig.~\ref{fig:file_stat_struct}. Il significato di detti tempi e dei relativi
campi è riportato nello schema in tab.~\ref{tab:file_file_times}, dove è anche
riportato un esempio delle funzioni che effettuano cambiamenti su di essi. Il
\end{table}
Il primo punto da tenere presente è la differenza fra il cosiddetto tempo di
-modifica (il \textit{modification time}, \var{st\_mtime}) e il tempo di
-cambiamento di stato (il \textit{change time}, \var{st\_ctime}). Il primo
-infatti fa riferimento ad una modifica del contenuto di un file, mentre il
-secondo ad una modifica \itindex{inode} dell'\textit{inode}; siccome esistono
-molte operazioni (come la funzione \func{link} e molte altre che vedremo in
-seguito) che modificano solo le informazioni contenute \itindex{inode}
+ultima modifica (il \textit{modification time}, \var{st\_mtime}) e il tempo di
+ultimo cambiamento di stato (il \textit{change time}, \var{st\_ctime}). Il
+primo infatti fa riferimento ad una modifica del contenuto di un file, mentre
+il secondo ad una modifica \itindex{inode} dell'\textit{inode}. Dato che
+esistono molte operazioni, come la funzione \func{link} e altre che vedremo in
+seguito, che modificano solo le informazioni contenute \itindex{inode}
nell'\textit{inode} senza toccare il contenuto del file, diventa necessario
-l'utilizzo di un altro tempo.
+l'utilizzo di questo secondo tempo.
Il tempo di ultima modifica viene usato ad esempio da programmi come
\cmd{make} per decidere quali file necessitano di essere ricompilati o
specificata esplicitamente.\footnote{si può comunque riottenere il vecchio
comportamento usando la opzione di montaggio \texttt{strictatime}.}
-L'effetto delle varie funzioni di manipolazione dei file sui relativi tempi è
-illustrato in tab.~\ref{tab:file_times_effects}, facendo riferimento al
-comportamento classico per quanto riguarda \var{st\_atime}. Si sono riportati
-gli effetti sia per il file a cui si fa riferimento, sia per la directory che
-lo contiene; questi ultimi possono essere capiti se si tiene conto di quanto
-già detto, e cioè che anche le directory sono file (che contengono una lista
-di nomi) che il sistema tratta in maniera del tutto analoga a tutti gli altri.
-
\begin{table}[htb]
\centering
\footnotesize
\label{tab:file_times_effects}
\end{table}
+
+L'effetto delle varie funzioni di manipolazione dei file sui relativi tempi è
+illustrato in tab.~\ref{tab:file_times_effects}, facendo riferimento al
+comportamento classico per quanto riguarda \var{st\_atime}. Si sono riportati
+gli effetti sia per il file a cui si fa riferimento, sia per la directory che
+lo contiene; questi ultimi possono essere capiti se si tiene conto di quanto
+già detto, e cioè che anche le directory sono anch'esse file che contengono
+una lista di nomi, che il sistema tratta in maniera del tutto analoga a tutti
+gli altri.
+
Per questo motivo tutte le volte che compiremo un'operazione su un file che
comporta una modifica del nome contenuto nella directory, andremo anche a
scrivere sulla directory che lo contiene cambiandone il tempo di modifica. Un
-esempio di questo può essere la cancellazione di un file, invece leggere o
-scrivere o cambiare i permessi di un file ha effetti solo sui tempi di
-quest'ultimo.
+esempio di questo tipo di operazione può essere la cancellazione di un file,
+invece leggere o scrivere o cambiare i permessi di un file ha effetti solo sui
+tempi di quest'ultimo.
Si noti infine come \var{st\_ctime} non abbia nulla a che fare con il tempo di
creazione del file, usato in molti altri sistemi operativi, ma che in Unix non
usando la funzione \funcd{utime}, il cui prototipo è:
\begin{prototype}{utime.h}
{int utime(const char *filename, struct utimbuf *times)}
-
- Cambia i tempi di ultimo accesso e modifica \itindex{inode}
- dell'\textit{inode} specificato da \param{filename} secondo i valori dei
- campi \var{actime} e \var{modtime} di \param{times}. Se questa è \val{NULL}
- allora viene usato il tempo corrente.
+ Modidica i tempi di ultimo accesso e modifica di un file.
\bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
errore, nel qual caso \var{errno} assumerà uno dei valori:
ed inoltre \errval{EROFS} e \errval{ENOENT}.}
\end{prototype}
-La funzione prende come argomento \param{times} una struttura
-\struct{utimbuf}, la cui definizione è riportata in
-fig.~\ref{fig:struct_utimebuf}, con la quale si possono specificare i nuovi
-valori che si vogliono impostare per tempi.
+La funzione cambia i tempi di ultimo accesso e modifica del file specificato
+dall'argomento \param{filename}, e richiede come secondo argomento il
+puntatore ad una struttura \struct{utimbuf}, la cui definizione è riportata in
+fig.~\ref{fig:struct_utimebuf}, con i nuovi valori di detti tempi
+(rispettivamente nei campi \var{actime} e \var{modtime}). Se si passa un
+puntatore nullo verrà impostato il tempo corrente.
\begin{figure}[!htb]
\footnotesize \centering
cosa è l'argomento \param{times}; se è \val{NULL} la funzione imposta il
tempo corrente ed è sufficiente avere accesso in scrittura al file; se invece
si è specificato un valore la funzione avrà successo solo se si è proprietari
-del file (o si hanno i privilegi di amministratore).
+del file o si hanno i privilegi di amministratore.
Si tenga presente che non è comunque possibile specificare il tempo di
-cambiamento di stato del file, che viene comunque cambiato dal kernel tutte le
-volte che si modifica \itindex{inode} l'\textit{inode} (quindi anche alla
-chiamata di \func{utime}). Questo serve anche come misura di sicurezza per
-evitare che si possa modificare un file nascondendo completamente le proprie
-tracce. In realtà la cosa resta possibile, se si è in grado di accedere al
-\index{file!di~dispositivo} file di dispositivo, scrivendo direttamente sul
+cambiamento di stato del file, che viene aggiornato direttamente dal kernel
+tutte le volte che si modifica \itindex{inode} l'\textit{inode} (quindi anche
+alla chiamata di \func{utime}). Questo serve anche come misura di sicurezza
+per evitare che si possa modificare un file nascondendo completamente le
+proprie tracce. In realtà la cosa resta possibile se si è in grado di accedere
+al \index{file!di~dispositivo} file di dispositivo, scrivendo direttamente sul
disco senza passare attraverso il filesystem, ma ovviamente in questo modo la
-cosa è molto più complicata da realizzare.
+cosa è più complicata da realizzare.
A partire dal kernel 2.6 la risoluzione dei tempi dei file, che nei campi di
tab.~\ref{tab:file_file_times} è espressa in secondi, è stata portata ai
\begin{prototype}
{sys/time.h}
{int utimes(const char *filename, struct timeval times[2])}
-
- Cambia i tempi di ultimo accesso e modifica \itindex{inode}
- dell'\textit{inode} specificato da \param{filename} secondo i valori
- specificati da \param{times}. Se questo è \val{NULL} allora viene usato il
- tempo corrente.
+ Modidica i tempi di ultimo accesso e modifica di un file.
\bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
errore, nel qual caso \var{errno} assumerà uno dei valori:
\end{prototype}
La funzione è del tutto analoga alla precedente \func{utime} ma usa come
-argomento \param{times}, un vettore di due strutture \struct{timeval}, la cui
+secondo argomento un vettore di due strutture \struct{timeval}, la cui
definizione è riportata in fig.~\ref{fig:sys_timeval_struct}, che consentono
di indicare i tempi con una precisione del microsecondo. Il primo elemento
di \param{times} indica il valore per il tempo di ultimo accesso, il secondo
-quello per il tempo di ultima modifica.
+quello per il tempo di ultima modifica. Se si indica come secondo argomento un
+puntatore nullo di nuovo verrà utilizzato il tempo corrente.
\begin{figure}[!htb]
\footnotesize \centering
Le due funzioni anno lo stesso comportamento di \texttt{utimes} e richiedono
gli stessi privilegi per poter operare, la differenza è che con \func{futimes}
si può indicare il file su cui operare facendo riferimento al relativo file
-descriptor (tratteremo in dettaglio l'argomento in
-sez.~\ref{cha:file_unix_interface}) mentre con \func{lutimes} nel caso in
-cui \param{filename} sia un link simbolico saranno modificati i suoi tempi
-invece di quelli del file a cui esso punta.
+descriptor mentre con \func{lutimes} nel caso in cui \param{filename} sia un
+link simbolico saranno modificati i suoi tempi invece di quelli del file a cui
+esso punta.
Nonostante il kernel, come accennato, supporti risoluzioni dei tempi dei file
fino al nanosecondo, le funzioni fin qui esaminate non consentono di impostare
sostanzialmente una estensione di \func{futimes} che consente di specificare i
tempi con precisione maggiore, la seconda supporta invece, rispetto ad
\func{utimes}, una sintassi più complessa che, come vedremo in
-sez.~\ref{sec:file_openat},\footnote{si rimanda pertanto la spiegazione del
- significato degli argomenti aggiuntivi alla trattazione generica delle varie
- funzioni che usano la stessa sintassi, effettuata in
- sez.~\ref{sec:file_openat}.} consente una indicazione sicura dei
+sez.~\ref{sec:file_openat} consente una indicazione sicura dei
\textit{pathname relativi} specificando la directory da usare come riferimento
in \param{dirfd} e la possibilità di usare \param{flags} per indicare alla
-funzione di dereferenziare o meno i link simbolici.
+funzione di dereferenziare o meno i link simbolici; si rimanda pertanto la
+spiegazione del significato degli argomenti aggiuntivi alla trattazione
+generica delle varie funzioni che usano la stessa sintassi, effettuata in
+sez.~\ref{sec:file_openat}.
\section{Il controllo di accesso ai file}
\end{enumerate}
Per alcuni filesystem\footnote{i filesystem più comuni (\textsl{ext2},
- \textsl{ext3}, \textsl{reiserfs}) supportano questa caratteristica, che è
- mutuata da BSD.} è inoltre prevista un'ulteriore misura di sicurezza, volta
-a scongiurare l'abuso dei \itindex{suid~bit} bit \acr{suid} e \acr{sgid}; essa
-consiste nel cancellare automaticamente questi bit dai permessi di un file
-qualora un processo che non appartenga all'amministratore\footnote{per la
- precisione un processo che non dispone della \itindex{capabilities} capacità
- \const{CAP\_FSETID}, vedi sez.~\ref{sec:proc_capabilities}.} effettui una
-scrittura. In questo modo anche se un utente malizioso scopre un file
-\acr{suid} su cui può scrivere, un'eventuale modifica comporterà la perdita di
-questo privilegio.
+ \textsl{ext3}, \textsl{ext4}, \textsl{reiserfs}) supportano questa
+ caratteristica, che è mutuata da BSD.} è inoltre prevista un'ulteriore
+misura di sicurezza, volta a scongiurare l'abuso dei \itindex{suid~bit} bit
+\acr{suid} e \acr{sgid}; essa consiste nel cancellare automaticamente questi
+bit dai permessi di un file qualora un processo che non appartenga
+all'amministratore\footnote{per la precisione un processo che non dispone
+ della \itindex{capabilities} capacità \const{CAP\_FSETID}, vedi
+ sez.~\ref{sec:proc_capabilities}.} effettui una scrittura. In questo modo
+anche se un utente malizioso scopre un file \acr{suid} su cui può scrivere,
+un'eventuale modifica comporterà la perdita di questo privilegio.
Le funzioni \func{chmod} e \func{fchmod} ci permettono di modificare i
permessi di un file, resta però il problema di quali sono i permessi assegnati
scopi di sicurezza, che sono state introdotte nelle versioni più recenti di
Linux.
+\subsection{Gli attributi estesi}
+\label{sec:file_xattr}
-\subsection{La gestione delle \textit{capabilities}}
-\label{sec:proc_capabilities}
-
-\itindbeg{capabilities}
-
-Come accennato in sez.~\ref{sec:proc_access_id} l'architettura classica della
-gestione dei privilegi in un sistema unix-like ha il sostanziale problema di
-fornire all'amministratore dei poteri troppo ampi, questo comporta che anche
-quando si siano predisposte delle misure di protezione per in essere in grado
-di difendersi dagli effetti di una eventuale compromissione del
-sistema,\footnote{come montare un filesystem in sola lettura per impedirne
- modifiche, o marcare un file come immutabile.} una volta che questa sia
-stata effettuata e si siano ottenuti i privilegi di amministratore, queste
-potranno essere comunque rimosse.\footnote{nei casi elencati nella precedente
- nota si potrà sempre rimontare il sistema in lettura-scrittura, o togliere
- la marcatura di immutabilità.}
-
-Il problema consiste nel fatto che nell'architettura tradizionale di un
-sistema unix-like i controlli di accesso sono basati su un solo livello di
-separazione: per i processi normali essi sono posti in atto, mentre per i
-processi con i privilegi di amministratore essi non vengono neppure eseguiti;
-per questo motivo non era previsto alcun modo per evitare che un processo con
-diritti di amministratore non potesse eseguire certe operazioni, o per cedere
-definitivamente alcuni privilegi da un certo momento in poi.
-
-Per ovviare a tutto ciò, a partire dai kernel della serie 2.2, è stato
-introdotto un meccanismo, detto \textit{capabilities}, che consentisse di
-suddividere i vari privilegi tradizionalmente associati all'amministratore in
-un insieme di \textsl{capacità} distinte. L'idea era che queste capacità
-potessero essere abilitate e disabilitate in maniera indipendente per ciascun
-processo con privilegi di amministratore, permettendo così una granularità
-molto più fine nella distribuzione degli stessi che evitasse la originaria
-situazione di ``\textsl{tutto o nulla}''.
-
-Il meccanismo completo delle \textit{capabilities}\footnote{l'implementazione
- si rifà ad una bozza di quello che doveva diventare lo standard POSIX.1e,
- poi abbandonato.} prevede inoltre la possibilità di associare le stesse ai
-singoli file eseguibili, in modo da poter stabilire quali capacità possono
-essere utilizzate quando viene messo in esecuzione uno specifico programma; ma
-il supporto per questa funzionalità è stato introdotto soltanto a partire dal
-kernel 2.6.24; fino ad allora doveva essere il programma stesso ad eseguire
-una riduzione esplicita delle sue capacità, cosa che ha reso l'uso di questa
-funzionalità poco diffuso, vista la presenza di meccanismi alternativi come
-\index{SELinux} SELinux.
-
-Per gestire questo meccanismo ciascun processo porta con sé tre distinti
-insiemi di \textit{capabilities}, che vengono denominati rispettivamente
-\textit{effective}, \textit{permitted} ed \textit{inherited}. Questi insiemi
-vengono mantenuti in forma di tre diverse maschere binarie,\footnote{il kernel
- li mantiene, come i vari identificatori di sez.~\ref{sec:proc_setuid},
- all'interno della \struct{task\_struct} di ciascun processo (vedi
- fig.~\ref{fig:proc_task_struct}), nei tre campi \texttt{cap\_effective},
- \texttt{cap\_inheritable}, \texttt{cap\_permitted} del tipo
- \texttt{kernel\_cap\_t}; questo è attualmente definito come intero a 32 bit,
- il che comporta un massimo di 32 \textit{capabilities} distinte.} in cui
-ciascun bit corrisponde ad una capacità diversa.
-
-L'utilizzo di tre distinti insiemi serve a fornire una interfaccia flessibile
-per l'uso delle \textit{capabilities}, con scopi analoghi a quelli per cui
-sono mantenuti i diversi insiemi di identificatori di
-sez.~\ref{sec:proc_setuid}; il loro significato è il seguente:
-\begin{basedescript}{\desclabelwidth{2.0cm}\desclabelstyle{\nextlinelabel}}
-\item[\textit{effective}] l'insieme delle \textit{capabilities}
- ``\textsl{effettive}'', cioè di quelle che vengono effettivamente usate dal
- kernel quando deve eseguire il controllo di accesso per le varie operazioni
- compiute dal processo.
-\item[\textit{permitted}] l'insieme delle \textit{capabilities}
- ``\textsl{permesse}'', cioè l'insieme di quelle capacità che un processo
- \textsl{può} impostare come \textsl{effettive}. Se un processo cancella una
- capacità da questo insieme non potrà più riassumerla (almeno che non esegua
- un programma che è \acr{suid} di root).
-\item[\textit{inherited}] l'insieme delle \textit{capabilities}
- ``\textsl{ereditabili}'', cioè quelle che vengono trasmesse ad un nuovo
- programma eseguito attraverso una chiamata ad \func{exec} (con l'eccezione
- del caso che questo sia \acr{suid} di root).
-\label{sec:capabilities_set}
-\end{basedescript}
-
-Oltre a questi tre insiemi, che sono relativi al singolo processo, il kernel
-mantiene un insieme generale valido per tutto il sistema, chiamato
-\itindex{capabilities~bounding~set} \textit{capabilities bounding set}. Ogni
-volta che un programma viene posto in esecuzione con \func{exec} il contenuto
-degli insiemi \textit{effective} e \textit{permitted} vengono mascherati con
-un \textsl{AND} binario del contenuto corrente del \textit{capabilities
- bounding set}, così che il nuovo processo potrà disporre soltanto delle
-capacità in esso elencate.
-
-Il \textit{capabilities bounding set} è un parametro di sistema, accessibile
-attraverso il contenuto del file \procfile{/proc/sys/kernel/cap-bound}, che per
-questa sua caratteristica consente di impostare un limite generale alle
-capacità che possono essere accordate ai vari processi. Questo valore può
-essere impostato ad un valore arbitrario esclusivamente dal primo processo
-eseguito nel sistema (di norma cioè da \texttt{/sbin/init}), ogni processo
-eseguito successivamente (cioè con \textsl{pid} diverso da 1) anche se
-eseguito con privilegi di amministratore potrà soltanto rimuovere uno dei bit
-già presenti dell'insieme: questo significa che una volta rimossa una
-\textit{capability} dal \textit{capabilities bounding set} essa non sarà più
-disponibile, neanche per l'amministratore, a meno di un riavvio.
+\itindbeg{Extended~Attributes}
-Quando un programma viene messo in esecuzione\footnote{cioè quando viene
- eseguita la \func{execve} con cui lo si lancia; in corrispondenza di una
- \func{fork} le \textit{capabilities} non vengono modificate.} esso eredita
-(nel senso che assume negli insiemi \textit{effective} e \textit{permitted})
-le \textit{capabilities} mantenute nell'insieme \textit{inherited}, a meno che
-non sia eseguito un programma \acr{suid} di root o la \func{exec} sia stata
-eseguita da un programma con \textsl{uid} reale zero; in tal caso il programma
-ottiene tutte le \textit{capabilities} presenti nel \textit{capabilities
- bounding set}. In questo modo si può far si che ad un processo eseguito in
-un secondo tempo possano essere trasmesse solo un insieme limitato di
-capacità, impedendogli di recuperare quelle assenti nell'insieme
-\textit{inherited}. Si tenga presente invece che attraverso una \func{fork}
-vengono mantenute le stesse capacità del processo padre.
+Nelle sezioni precedenti abbiamo trattato in dettaglio le varie informazioni
+che il sistema mantiene negli \itindex{inode} \textit{inode}, e le varie
+funzioni che permettono di modificarle. Si sarà notato come in realtà queste
+informazioni siano estremamente ridotte. Questo è dovuto al fatto che Unix
+origina negli anni '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
+trovare spazio nei dati classici mantenuti negli \itindex{inode}
+\textit{inode}.
+Per risolvere questo problema alcuni sistemi unix-like (e fra questi anche
+Linux) hanno introdotto un meccanismo generico, detto \textit{Extended
+ Attributes} che consenta di associare delle informazioni ai singoli
+file.\footnote{l'uso più comune è quello della ACL, che tratteremo nella
+ prossima sezione.} Gli \textsl{attributi estesi} non sono altro che delle
+coppie nome/valore che sono associate permanentemente ad un oggetto sul
+filesystem, analoghi di quello che sono le variabili di ambiente (vedi
+sez.~\ref{sec:proc_environ}) per un processo.
-% TODO verificare per process capability bounding set, vedi:
-% http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=3b7391de67da515c91f48aa371de77cb6cc5c07e
+Altri sistemi (come Solaris, MacOS e Windows) hanno adottato un meccanismo
+diverso in cui ad un file sono associati diversi flussi di dati, su cui
+possono essere mantenute ulteriori informazioni, che possono essere accedute
+con le normali operazioni di lettura e scrittura. Questi non vanno confusi con
+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, 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.
-% TODO capire cosa cambia con i patch vari, vedi
-% http://lwn.net/Articles/280279/
-% http://lwn.net/Articles/256519/
-% http://lwn.net/Articles/211883/
+In Linux gli attributi estesi sono sempre associati al singolo \itindex{inode}
+\textit{inode} e l'accesso viene sempre eseguito in forma atomica, in lettura
+il valore corrente viene scritto su un buffer in memoria, mentre la scrittura
+prevede che ogni valore precedente sia sovrascritto.
+Si tenga presente che non tutti i filesystem supportano gli \textit{Extended
+ Attributes}; al momento della scrittura di queste dispense essi sono
+presenti solo sui vari \textsl{extN}, \textsl{ReiserFS}, \textsl{JFS},
+\textsl{XFS} e \textsl{Btrfs}.\footnote{l'elenco è aggiornato a Luglio 2011.}
+Inoltre a seconda della implementazione ci possono essere dei limiti sulla
+quantità di attributi che si possono utilizzare.\footnote{ad esempio nel caso
+ di \textsl{ext2} ed \textsl{ext3} è richiesto che essi siano contenuti
+ all'interno di un singolo blocco (pertanto con dimensioni massime pari a
+ 1024, 2048 o 4096 byte a seconda delle dimensioni di quest'ultimo impostate
+ in fase di creazione del filesystem), mentre con \textsl{XFS} non ci sono
+ limiti ed i dati vengono memorizzati in maniera diversa (nell'\textit{inode}
+ stesso, in un blocco a parte, o in una struttura ad albero dedicata) per
+ mantenerne la scalabilità.} Infine lo spazio utilizzato per mantenere gli
+attributi estesi viene tenuto in conto per il calcolo delle quote di utente e
+gruppo proprietari del file.
-Un elenco delle delle \textit{capabilities} disponibili su Linux, con una
-breve descrizione ed il nome delle costanti che le identificano, è riportato
-in tab.~\ref{tab:proc_capabilities};\footnote{l'elenco presentato questa
- tabella, ripreso dalla pagina di manuale (accessibile con \texttt{man
- capabilities}) e dalle definizioni in \texttt{linux/capabilities.h}, è
- aggiornato al kernel 2.6.26.} la tabella è divisa in due parti, la prima
-riporta le \textit{capabilities} previste anche nella bozza dello standard
-POSIX1.e, la seconda quelle specifiche di Linux. Come si può notare dalla
-tabella alcune \textit{capabilities} attengono a singole funzionalità e sono
-molto specializzate, mentre altre hanno un campo di applicazione molto vasto,
-che è opportuno dettagliare maggiormente.
+Come meccanismo per mantenere informazioni aggiuntive associate al singolo
+file, gli \textit{Extended Attributes} possono avere usi anche molto diversi
+fra loro. Per poterli distinguere allora sono stati suddivisi in
+\textsl{classi}, a cui poter applicare requisiti diversi per l'accesso e la
+gestione. Per questo motivo il nome di un attributo deve essere sempre
+specificato nella forma \texttt{namespace.attribute}, dove \texttt{namespace}
+fa riferimento alla classe a cui l'attributo appartiene, mentre
+\texttt{attribute} è il nome ad esso assegnato. In tale forma il nome di un
+attributo esteso deve essere univoco. Al momento\footnote{della scrittura di
+ questa sezione, kernel 2.6.23, ottobre 2007.} sono state definite le quattro
+classi di attributi riportate in tab.~\ref{tab:extended_attribute_class}.
-\begin{table}[!h!bt]
+\begin{table}[htb]
\centering
\footnotesize
\begin{tabular}{|l|p{12cm}|}
\hline
- \textbf{Capacità}&\textbf{Descrizione}\\
+ \textbf{Nome} & \textbf{Descrizione} \\
\hline
\hline
-%
-% POSIX-draft defined capabilities.
-%
- \const{CAP\_AUDIT\_WRITE}&La capacità di scrivere dati nel giornale di
- auditing del kernel (dal kernel 2.6.11).\\
- \const{CAP\_AUDIT\_CONTROL}& La capacità di abilitare e disabilitare il
- controllo dell'auditing (dal kernel 2.6.11).\\
- % TODO verificare questa roba dell'auditing
- \const{CAP\_CHOWN} & La capacità di cambiare proprietario e gruppo
- proprietario di un file (vedi
- sez.~\ref{sec:file_ownership_management}).\\
- \const{CAP\_DAC\_OVERRIDE}& La capacità di evitare il controllo dei
- permessi di lettura, scrittura ed esecuzione dei
- file,\footnotemark (vedi
- sez.~\ref{sec:file_access_control}).\\
- \const{CAP\_DAC\_READ\_SEARCH}& La capacità di evitare il controllo dei
- permessi di lettura ed esecuzione per
- le directory (vedi
- sez.~\ref{sec:file_access_control}).\\
- \const{CAP\_FOWNER} & La capacità di evitare il controllo della
- proprietà di un file per tutte
- le operazioni privilegiate non coperte dalle
- precedenti \const{CAP\_DAC\_OVERRIDE} e
- \const{CAP\_DAC\_READ\_SEARCH}.\\
- \const{CAP\_FSETID} & La capacità di evitare la cancellazione
- automatica dei bit \itindex{suid~bit} \acr{suid}
- e \itindex{sgid~bit} \acr{sgid} quando un file
- per i quali sono impostati viene modificato da
- un processo senza questa capacità e la capacità
- di impostare il bit \acr{sgid} su un file anche
- quando questo è relativo ad un gruppo cui non si
- appartiene (vedi
- sez.~\ref{sec:file_perm_management}).\\
- \const{CAP\_SETFCAP} & La capacità di impostare le
- \textit{capabilities} di un file (dal kernel
- 2.6.24).\\
- \const{CAP\_KILL} & La capacità di mandare segnali a qualunque
- processo (vedi sez.~\ref{sec:sig_kill_raise}).\\
- \const{CAP\_SETGID} & La capacità di manipolare i group ID dei
- processi, sia il principale che i supplementari,
- (vedi sez.~\ref{sec:proc_setgroups}) che quelli
- trasmessi tramite i socket \textit{unix domain}
- (vedi sez.~\ref{sec:unix_socket}).\\
- \const{CAP\_SETUID} & La capacità di manipolare gli user ID del
- processo (vedi sez.~\ref{sec:proc_setuid}) e di
- trasmettere un user ID arbitrario nel passaggio
- delle credenziali coi socket \textit{unix
- domain} (vedi sez.~\ref{sec:unix_socket}).\\
-%
-% Linux specific capabilities
-%
-\hline
- \const{CAP\_IPC\_LOCK} & La capacità di effettuare il \textit{memory
- locking} \itindex{memory~locking} con le
- funzioni \func{mlock}, \func{mlockall},
- \func{shmctl}, \func{mmap} (vedi
- sez.~\ref{sec:proc_mem_lock} e
- sez.~\ref{sec:file_memory_map}). \\
- \const{CAP\_IPC\_OWNER} & La capacità di evitare il controllo dei permessi
- per le operazioni sugli oggetti di
- intercomunicazione fra processi (vedi
- sez.~\ref{sec:ipc_sysv}).\\
- \const{CAP\_LEASE} & La capacità di creare dei \textit{file lease}
- \index{file!lease} (vedi
- sez.~\ref{sec:file_asyncronous_lease})
- pur non essendo proprietari del file (dal kernel
- 2.4).\\
- \const{CAP\_LINUX\_IMMUTABLE}& La capacità di impostare sui file gli
- attributi \textit{immutable} e
- \itindex{append~mode} \textit{append only} (se
- supportati).\\
- \const{CAP\_MKNOD} & La capacità di creare
- \index{file!di~dispositivo} file di dispositivo
- con \func{mknod} (vedi
- sez.~\ref{sec:file_mknod}) (dal kernel 2.4).\\
- \const{CAP\_NET\_ADMIN} & La capacità di eseguire alcune operazioni
- privilegiate sulla rete.\\
- \const{CAP\_NET\_BIND\_SERVICE}& La capacità di porsi in ascolto
- su porte riservate (vedi
- sez.~\ref{sec:TCP_func_bind}).\\
- \const{CAP\_NET\_BROADCAST}& La capacità di consentire l'uso di socket in
- \itindex{broadcast} \textit{broadcast} e
- \itindex{multicast} \textit{multicast}.\\
- \const{CAP\_NET\_RAW} & La capacità di usare socket \texttt{RAW} e
- \texttt{PACKET} (vedi sez.~\ref{sec:sock_type}).\\
- \const{CAP\_SETPCAP} & La capacità di impostare o rimuovere una
- capacità.\\
- % TODO cambiata nel 2.4.24 rc1 ?
- \const{CAP\_SYS\_ADMIN} & La capacità di eseguire una serie di compiti
- amministrativi. \\
- \const{CAP\_SYS\_BOOT} & La capacità di fare eseguire un riavvio del
- sistema.\\
-% TODO trattare reboot e kexec
- \const{CAP\_SYS\_CHROOT}& La capacità di eseguire la funzione
- \func{chroot} (vedi
- sez.~\ref{sec:file_chroot}).\\
- \const{CAP\_MAC\_ADMIN} & La capacità amministrare il MAC di Smack (dal
- kernel 2.6.25).\\
- \const{CAP\_MAC\_OVERRIDE}& La capacità evitare il MAC di Smack (dal
- kernel 2.6.25).\\
- \const{CAP\_SYS\_MODULE}& La capacità di caricare e rimuovere moduli del
- kernel. \\
- \const{CAP\_SYS\_NICE} & La capacità di modificare le priorità dei
- processi. \\
- \const{CAP\_SYS\_PACCT} & La capacità di usare le funzioni di
- \textit{accounting} dei processi (vedi
- sez.~\ref{sec:sys_bsd_accounting}).\\
- \const{CAP\_SYS\_PTRACE}& La capacità di tracciare qualunque processo con
- \func{ptrace} (vedi
- sez.~\ref{sec:xxx_ptrace}).\\
- \const{CAP\_SYS\_RAWIO} & La capacità di eseguire operazioni sulle porte
- di I/O con \func{ioperm} e \func{iopl} (vedi
- sez.~\ref{sec:file_io_port}).\\
- \const{CAP\_SYS\_RESOURCE}& La capacità di superare le limitazioni sulle
- risorse.\\
- \const{CAP\_SYS\_TIME} & La capacità di modificare il tempo di sistema
- (vedi sez.~\ref{sec:sys_time}).\\
- \const{CAP\_SYS\_TTY\_CONFIG}& La capacità di simulare un \textit{hangup}
- della console, con la funzione
- \func{vhangup}.\\
+ \texttt{security}&Gli \textit{extended security attributes}: vengono
+ utilizzati dalle estensioni di sicurezza del kernel (i
+ \itindex{Linux~Security~Modules} \textit{Linux
+ Security Modules}), per le realizzazione di meccanismi
+ evoluti di controllo di accesso come \index{SELinux}
+ SELinux o le \textit{capabilities} dei file di
+ sez.~\ref{sec:proc_capabilities}.\\
+ \texttt{system} & Gli \textit{extended security attributes}: sono usati
+ dal kernel per memorizzare dati di sistema associati ai
+ file come le \itindex{Access~Control~List} ACL (vedi
+ sez.~\ref{sec:file_ACL}) o le \itindex{capabilities}
+ \textit{capabilities} (vedi
+ sez.~\ref{sec:proc_capabilities}).\\
+ \texttt{trusted}& I \textit{trusted extended attributes}: vengono
+ utilizzati per poter realizzare in user space
+ meccanismi che consentano di mantenere delle
+ informazioni sui file che non devono essere accessibili
+ ai processi ordinari.\\
+ \texttt{user} & Gli \textit{extended user attributes}: utilizzati per
+ mantenere informazioni aggiuntive sui file (come il
+ \textit{mime-type}, la codifica dei caratteri o del
+ file) accessibili dagli utenti.\\
\hline
\end{tabular}
- \caption{Le costanti che identificano le \textit{capabilities} presenti nel
- kernel.}
-\label{tab:proc_capabilities}
+ \caption{I nomi utilizzati valore di \texttt{namespace} per distinguere le
+ varie classi di \textit{Extended Attributes}.}
+ \label{tab:extended_attribute_class}
\end{table}
-\footnotetext{vale a dire i permessi caratteristici del modello classico del
- controllo di accesso chiamato \itindex{Discrectionary~Access~Control~(DAC)}
- \textit{Discrectionary Access Control} (da cui il nome DAC).}
-
-% TODO aggiungere CAP_SYSLOG, citata in http://lwn.net/Articles/429595/
-La prima di queste capacità ``\textsl{ampie}'' è \const{CAP\_FOWNER}, che
-rimuove le restrizioni poste ad un processo che non ha la proprietà di un file
-in un vasto campo di operazioni;\footnote{vale a dire la richiesta che
- l'user-ID effettivo del processo (o meglio il \textit{filesystem user-ID},
- vedi sez.~\ref{sec:proc_setuid}) coincida con quello del proprietario.}
-queste comprendono i cambiamenti dei permessi e dei tempi del file (vedi
-sez.~\ref{sec:file_perm_management} e sez.~\ref{sec:file_file_times}), le
-impostazioni degli attributi estesi e delle ACL (vedi
-sez.~\ref{sec:file_xattr} e \ref{sec:file_ACL}), poter ignorare lo
-\itindex{sticky~bit} \textit{sticky bit} nella cancellazione dei file (vedi
-sez.~\ref{sec:file_special_perm}), la possibilità di impostare il flag di
-\const{O\_NOATIME} con \func{open} e \func{fcntl} (vedi
-sez.~\ref{sec:file_open} e sez.~\ref{sec:file_fcntl}) senza restrizioni.
+Dato che uno degli usi degli \textit{Extended Attributes} è quello che li
+impiega per realizzare delle estensioni (come le \itindex{Access~Control~List}
+ACL, \index{SELinux} SELinux, ecc.) al tradizionale meccanismo dei controlli
+di accesso di Unix, l'accesso ai loro valori viene regolato in maniera diversa
+a seconda sia della loro classe sia di quali, fra le estensioni che li
+utilizzano, sono poste in uso. In particolare, per ciascuna delle classi
+riportate in tab.~\ref{tab:extended_attribute_class}, si hanno i seguenti
+casi:
+\begin{basedescript}{\desclabelwidth{1.7cm}\desclabelstyle{\nextlinelabel}}
+\item[\texttt{security}] L'accesso agli \textit{extended security attributes}
+ dipende dalle politiche di sicurezza stabilite da loro stessi tramite
+ l'utilizzo di un sistema di controllo basato sui
+ \itindex{Linux~Security~Modules} \textit{Linux Security Modules} (ad esempio
+ \index{SELinux} SELinux). Pertanto l'accesso in lettura o scrittura dipende
+ dalle politiche di sicurezza implementate all'interno dal modulo di
+ sicurezza che si sta utilizzando al momento (ciascuno avrà le sue). Se non è
+ stato caricato nessun modulo di sicurezza l'accesso in lettura sarà
+ consentito a tutti i processi, mentre quello in scrittura solo ai processi
+ con privilegi amministrativi dotati della \index{capabilities}
+ \textit{capability} \const{CAP\_SYS\_ADMIN}.
-Una seconda capacità che copre diverse operazioni, in questo caso riguardanti
-la rete, è \const{CAP\_NET\_ADMIN}, che consente di impostare le opzioni
-privilegiate dei socket (vedi sez.~\ref{sec:sock_generic_options}), abilitare
-il \itindex{multicast} \textit{multicasting}, eseguire la configurazione delle
-interfacce di rete (vedi sez.~\ref{sec:sock_ioctl_netdevice}) ed impostare la
-tabella di instradamento.
+\item[\texttt{system}] Anche l'accesso agli \textit{extended system
+ attributes} dipende dalle politiche di accesso che il kernel realizza
+ anche utilizzando gli stessi valori in essi contenuti. Ad esempio nel caso
+ delle \itindex{Access~Control~List} ACL l'accesso è consentito in lettura ai
+ processi che hanno la capacità di eseguire una ricerca sul file (cioè hanno
+ il permesso di lettura sulla directory che contiene il file) ed in scrittura
+ al proprietario del file o ai processi dotati della \textit{capability}
+ \index{capabilities} \const{CAP\_FOWNER}.\footnote{vale a dire una politica
+ di accesso analoga a quella impiegata per gli ordinari permessi dei file.}
-Una terza \textit{capability} con vasto campo di applicazione è
-\const{CAP\_SYS\_ADMIN}, che copre una serie di operazioni amministrative,
-come impostare le quote disco (vedi sez.\ref{sec:disk_quota}), attivare e
-disattivare la swap, montare, rimontare e smontare filesystem (vedi
-sez.~\ref{sec:sys_file_config}), effettuare operazioni di controllo sugli
-oggetti dell'IPC di SysV (vedi sez.~\ref{sec:ipc_sysv}), operare sugli
-attributi estesi di classe \texttt{security} o \texttt{trusted} (vedi
-sez.~\ref{sec:file_xattr}), specificare un user-ID arbitrario nella
-trasmissione delle credenziali dei socket (vedi sez.~\ref{sec:socket_xxx}),
-assegnare classi privilegiate per lo scheduling dell'I/O (vedi
-sez.~\ref{sec:io_priority}), superare il limite di sistema sul numero massimo
-di file aperti,\footnote{quello indicato da \procfile{/proc/sys/fs/file-max}.}
-effettuare operazioni privilegiate sulle chiavi mantenute dal kernel (vedi
-sez.~\ref{sec:io_priority}), usare la funzione \func{lookup\_dcookie} (vedi
-sez.~\ref{sec:xxx_profiling}), usare \const{CLONE\_NEWNS} con \func{unshare},
-(vedi sez.~\ref{sec:process_clone}).
+\item[\texttt{trusted}] L'accesso ai \textit{trusted extended attributes}, sia
+ per la lettura che per la scrittura, è consentito soltanto ai processi con
+ privilegi amministrativi dotati della \index{capabilities}
+ \textit{capability} \const{CAP\_SYS\_ADMIN}. In questo modo si possono
+ utilizzare questi attributi per realizzare in user space dei meccanismi di
+ controllo che accedono ad informazioni non disponibili ai processi ordinari.
-Originariamente \const{CAP\_SYS\_NICE} riguardava soltanto la capacità di
-aumentare le priorità di esecuzione dei processi, come la diminuzione del
-valore di \textit{nice} (vedi sez.~\ref{sec:proc_sched_stand}), l'uso delle
-priorità \textit{real-time} (vedi sez.~\ref{sec:proc_real_time}), o
-l'impostazione delle affinità di processore (vedi
-sez.~\ref{sec:proc_sched_multiprocess}); ma con l'introduzione di priorità
-anche riguardo le operazioni di accesso al disco, e, nel caso di sistemi NUMA,
-alla memoria, essa viene a coprire anche la possibilità di assegnare priorità
-arbitrarie nell'accesso a disco (vedi sez.~\ref{sec:io_priority}) e nelle
-politiche di allocazione delle pagine di memoria ai nodi di un sistema NUMA.
+\item[\texttt{user}] L'accesso agli \textit{extended user attributes} è
+ regolato dai normali permessi dei file: occorre avere il permesso di lettura
+ per leggerli e quello di scrittura per scriverli o modificarli. Dato l'uso
+ di questi attributi si è scelto di applicare al loro accesso gli stessi
+ criteri che si usano per l'accesso al contenuto dei file (o delle directory)
+ cui essi fanno riferimento. Questa scelta vale però soltanto per i file e le
+ directory ordinarie, se valesse in generale infatti si avrebbe un serio
+ problema di sicurezza dato che esistono diversi oggetti sul filesystem per i
+ quali è normale avere avere il permesso di scrittura consentito a tutti gli
+ utenti, come i link simbolici, o alcuni \index{file!di~dispositivo} file di
+ dispositivo come \texttt{/dev/null}. Se fosse possibile usare su di essi gli
+ \textit{extended user attributes} un utente qualunque potrebbe inserirvi
+ dati a piacere.\footnote{la cosa è stata notata su XFS, dove questo
+ comportamento permetteva, non essendovi limiti sullo spazio occupabile
+ dagli \textit{Extended Attributes}, di bloccare il sistema riempiendo il
+ disco.}
-Infine la \textit{capability} \const{CAP\_SYS\_RESOURCE} attiene alla
-possibilità di superare i limiti imposti sulle risorse di sistema, come usare
-lo spazio disco riservato all'amministratore sui filesystem che lo supportano,
-usare la funzione \func{ioctl} per controllare il \textit{journaling} sul
-filesystem \acr{ext3}, non subire le quote disco, aumentare i limiti sulle
-risorse (vedi sez.~\ref{sec:sys_resource_limit}) e sulle dimensioni dei
-messaggi delle code del SysV IPC (vedi sez.~\ref{sec:ipc_sysv_mq}).
+ La semantica del controllo di accesso indicata inoltre non avrebbe alcun
+ senso al di fuori di file e directory: i permessi di lettura e scrittura per
+ un \index{file!di~dispositivo} file di dispositivo attengono alle capacità
+ di accesso al dispositivo sottostante,\footnote{motivo per cui si può
+ formattare un disco anche se \texttt{/dev} è su un filesystem in sola
+ lettura.} mentre per i link simbolici questi vengono semplicemente
+ ignorati: in nessuno dei due casi hanno a che fare con il contenuto del
+ file, e nella discussione relativa all'uso degli \textit{extended user
+ attributes} nessuno è mai stato capace di indicare una qualche forma
+ sensata di utilizzo degli stessi per link simbolici o
+ \index{file!di~dispositivo} file di dispositivo, e neanche per le fifo o i
+ socket. Per questo motivo essi sono stati completamente disabilitati per
+ tutto ciò che non sia un file regolare o una directory.\footnote{si può
+ verificare la semantica adottata consultando il file \texttt{fs/xattr.c}
+ dei sorgenti del kernel.} Inoltre per le directory è stata introdotta una
+ ulteriore restrizione, dovuta di nuovo alla presenza ordinaria di permessi
+ di scrittura completi su directory come \texttt{/tmp}. Per questo motivo,
+ per evitare eventuali abusi, se una directory ha lo \itindex{sticky~bit}
+ \textit{sticky bit} attivo sarà consentito scrivere i suoi \textit{extended
+ user attributes} soltanto se si è proprietari della stessa, o si hanno i
+ privilegi amministrativi della capability \index{capabilities}
+ \const{CAP\_FOWNER}.
+\end{basedescript}
+Le funzioni per la gestione degli attributi estesi, come altre funzioni di
+gestione avanzate specifiche di Linux, non fanno parte delle \acr{glibc}, e
+sono fornite da una apposita libreria, \texttt{libattr}, che deve essere
+installata a parte;\footnote{la versione corrente della libreria è
+ \texttt{libattr1}.} pertanto se un programma le utilizza si dovrà indicare
+esplicitamente l'uso della suddetta libreria invocando il compilatore con
+l'opzione \texttt{-lattr}.
-Per la gestione delle \textit{capabilities} il kernel mette a disposizione due
-funzioni che permettono rispettivamente di leggere ed impostare i valori dei
-tre insiemi illustrati in precedenza. Queste due funzioni sono \funcd{capget}
-e \funcd{capset} e costituiscono l'interfaccia di gestione basso livello; i
-loro rispettivi prototipi sono:
+Per poter leggere gli attributi estesi sono disponibili tre diverse funzioni,
+\funcd{getxattr}, \funcd{lgetxattr} e \funcd{fgetxattr}, che consentono
+rispettivamente di richiedere gli attributi relativi a un file, a un link
+simbolico e ad un file descriptor; i rispettivi prototipi sono:
\begin{functions}
- \headdecl{sys/capability.h}
+ \headdecl{sys/types.h}
+ \headdecl{attr/xattr.h}
+
+ \funcdecl{ssize\_t getxattr(const char *path, const char *name, void
+ *value, size\_t size)}
- \funcdecl{int capget(cap\_user\_header\_t hdrp, cap\_user\_data\_t datap)}
- Legge le \textit{capabilities}.
+ \funcdecl{ssize\_t lgetxattr(const char *path, const char *name, void
+ *value, size\_t size)}
- \funcdecl{int capset(cap\_user\_header\_t hdrp, const cap\_user\_data\_t
- datap)}
- Imposta le \textit{capabilities}.
+ \funcdecl{ssize\_t fgetxattr(int filedes, const char *name, void *value,
+ size\_t size)}
+ Le funzioni leggono il valore di un attributo esteso.
- \bodydesc{Entrambe le funzioni ritornano 0 in caso di successo e -1 in caso
- di errore, nel qual caso \var{errno} può assumere i valori:
- \begin{errlist}
- \item[\errcode{ESRCH}] si è fatto riferimento ad un processo inesistente.
- \item[\errcode{EPERM}] si è tentato di aggiungere una capacità
- nell'insieme delle \textit{capabilities} permesse, o di impostare una
- capacità non presente nell'insieme di quelle permesse negli insieme
- delle effettive o ereditate, o si è cercato di impostare una
- \textit{capability} di un altro processo senza avare
- \const{CAP\_SETPCAP}.
+ \bodydesc{Le funzioni restituiscono un intero positivo che indica la
+ dimensione dell'attributo richiesto in caso di successo, e $-1$ in caso di
+ errore, nel qual caso \var{errno} assumerà i valori:
+ \begin{errlist}
+ \item[\errcode{ENOATTR}] l'attributo richiesto non esiste.
+ \item[\errcode{ERANGE}] la dimensione \param{size} del buffer \param{value}
+ non è sufficiente per contenere il risultato.
+ \item[\errcode{ENOTSUP}] gli attributi estesi non sono supportati dal
+ filesystem o sono disabilitati.
\end{errlist}
- ed inoltre \errval{EFAULT} ed \errval{EINVAL}.
-}
-
+ e tutti gli errori di \func{stat}, come \errcode{EPERM} se non si hanno i
+ permessi di accesso all'attributo. }
\end{functions}
-Queste due funzioni prendono come argomenti due tipi di dati dedicati,
-definiti come puntatori a due strutture specifiche di Linux, illustrate in
-fig.~\ref{fig:cap_kernel_struct}. Per poterle utilizzare occorre anche
-cancellare la macro \macro{\_POSIX\_SOURCE}.\footnote{per farlo occorre
- utilizzare la direttiva di preprocessore \direct{undef}; si dovrà cioè
- inserire una istruzione \texttt{\#undef \_POSIX\_SOURCE} prima di includere
- \texttt{sys/capability.h}.} Si tenga presente che le strutture di
-fig.~\ref{fig:cap_kernel_struct}, come i prototipi delle due funzioni
-\func{capget} e \func{capset}, sono soggette ad essere modificate con il
-cambiamento del kernel (in particolare i tipi di dati delle strutture) ed
-anche se finora l'interfaccia è risultata stabile, non c'è nessuna
-assicurazione che questa venga mantenuta.\footnote{anzi, visto lo scarso
- utilizzo di questa funzionalità ci sono state varie discussioni fra gli
- sviluppatori del kernel relative all'eliminarla o al modificarla
- radicalmente.} Pertanto se si vogliono scrivere programmi portabili che
-possano essere eseguiti su qualunque versione del kernel è opportuno
-utilizzare le interfacce di alto livello.
-
-\begin{figure}[!htb]
- \footnotesize
- \centering
- \begin{minipage}[c]{15cm}
- \includestruct{listati/cap_user_header_t.h}
- \end{minipage}
- \normalsize
- \caption{Definizione delle strutture a cui fanno riferimento i puntatori
- \structd{cap\_user\_header\_t} e \structd{cap\_user\_data\_t} usati per
- l'interfaccia di gestione di basso livello delle \textit{capabilities}.}
- \label{fig:cap_kernel_struct}
-\end{figure}
-
-La struttura a cui deve puntare l'argomento \param{hdrp} serve ad indicare,
-tramite il campo \var{pid}, il processo del quale si vogliono leggere o
-modificare le \textit{capabilities}. Il campo \var{version} deve essere
-impostato al valore della versione delle usata dal kernel (quello indicato
-dalla costante \const{\_LINUX\_CAPABILITY\_VERSION} di
-fig.~\ref{fig:cap_kernel_struct}) altrimenti le funzioni ritorneranno con un
-errore di \errcode{EINVAL}, restituendo nel campo stesso il valore corretto
-della versione in uso. La struttura a cui deve puntare l'argomento
-\param{datap} invece conterrà i valori letti o da impostare per i tre insiemi
-delle capacità del processo.
+Le funzioni \func{getxattr} e \func{lgetxattr} prendono come primo argomento
+un pathname che indica il file di cui si vuole richiedere un attributo, la
+sola differenza è che la seconda, se il pathname indica un link simbolico,
+restituisce gli attributi di quest'ultimo e non quelli del file a cui esso fa
+riferimento. La funzione \func{fgetxattr} prende invece come primo argomento
+un numero di file descriptor, e richiede gli attributi del file ad esso
+associato.
-Dato che le precedenti funzioni, oltre ad essere specifiche di Linux, non
-garantiscono la stabilità nell'interfaccia, è sempre opportuno effettuare la
-gestione delle \textit{capabilities} utilizzando le funzioni di libreria a
-questo dedicate. Queste funzioni, che seguono quanto previsto nelle bozze
-dello standard POSIX.1e, non fanno parte delle \acr{glibc} e sono fornite in
-una libreria a parte,\footnote{la libreria è \texttt{libcap2}, nel caso di
- Debian può essere installata con il pacchetto omonimo.} pertanto se un
-programma le utilizza si dovrà indicare esplicitamente l'uso della suddetta
-libreria attraverso l'opzione \texttt{-lcap} del compilatore.
+Tutte e tre le funzioni richiedono di specificare nell'argomento \param{name}
+il nome dell'attributo di cui si vuole ottenere il valore. Il nome deve essere
+indicato comprensivo di prefisso del \textit{namespace} cui appartiene (uno
+dei valori di tab.~\ref{tab:extended_attribute_class}) nella forma
+\texttt{namespace.attributename}, come stringa terminata da un carattere NUL.
+Il suo valore verrà restituito nel buffer puntato dall'argomento \param{value}
+per una dimensione massima di \param{size} byte;\footnote{gli attributi estesi
+ possono essere costituiti arbitrariamente da dati testuali o binari.} se
+quest'ultima non è sufficiente si avrà un errore di \errcode{ERANGE}.
-Le funzioni dell'interfaccia delle bozze di POSIX.1e prevedono l'uso di uno
-tipo di dato opaco, \type{cap\_t}, come puntatore ai dati mantenuti nel
-cosiddetto \textit{capability state},\footnote{si tratta in sostanza di un
- puntatore ad una struttura interna utilizzata dalle librerie, i cui campi
- non devono mai essere acceduti direttamente.} in sono memorizzati tutti i
-dati delle \textit{capabilities}. In questo modo è possibile mascherare i
-dettagli della gestione di basso livello, che potranno essere modificati senza
-dover cambiare le funzioni dell'interfaccia, che faranno riferimento soltanto
-ad oggetti di questo tipo. L'interfaccia pertanto non soltanto fornisce le
-funzioni per modificare e leggere le \textit{capabilities}, ma anche quelle
-per gestire i dati attraverso \type{cap\_t}.
+Per evitare di dover indovinare la dimensione di un attributo per tentativi si
+può eseguire una interrogazione utilizzando un valore nullo per \param{size};
+in questo caso non verrà letto nessun dato, ma verrà restituito come valore di
+ritorno della funzione chiamata la dimensione totale dell'attributo esteso
+richiesto, che si potrà usare come stima per allocare un buffer di dimensioni
+sufficienti.\footnote{si parla di stima perché anche se le funzioni
+ restituiscono la dimensione esatta dell'attributo al momento in cui sono
+ eseguite, questa potrebbe essere modificata in qualunque momento da un
+ successivo accesso eseguito da un altro processo.}
-La prima funzione dell'interfaccia è quella che permette di inizializzare un
-\textit{capability state}, allocando al contempo la memoria necessaria per i
-relativi dati. La funzione è \funcd{cap\_init} ed il suo prototipo è:
+Un secondo gruppo di funzioni è quello che consente di impostare il valore di
+un attributo esteso, queste sono \funcd{setxattr}, \funcd{lsetxattr} e
+\funcd{fsetxattr}, e consentono di operare rispettivamente su un file, su un
+link simbolico o specificando un file descriptor; i loro prototipi sono:
\begin{functions}
- \headdecl{sys/capability.h}
-
- \funcdecl{cap\_t cap\_init(void)}
- Crea ed inizializza un \textit{capability state}.
+ \headdecl{sys/types.h}
+ \headdecl{attr/xattr.h}
- \bodydesc{La funzione ritorna un valore non nullo in caso di successo e
- \macro{NULL} in caso di errore, nel qual caso \var{errno} assumerà il
- valore \errval{ENOMEM}.
- }
-\end{functions}
+ \funcdecl{int setxattr(const char *path, const char *name, const void
+ *value, size\_t size, int flags)}
-La funzione restituisce il puntatore \type{cap\_t} ad uno stato inizializzato
-con tutte le \textit{capabilities} azzerate. In caso di errore (cioè quando
-non c'è memoria sufficiente ad allocare i dati) viene restituito \macro{NULL}
-ed \var{errno} viene impostata a \errval{ENOMEM}. La memoria necessaria a
-mantenere i dati viene automaticamente allocata da \func{cap\_init}, ma dovrà
-essere disallocata esplicitamente quando non è più necessaria utilizzando, per
-questo l'interfaccia fornisce una apposita funzione, \funcd{cap\_free}, il cui
-prototipo è:
-\begin{functions}
- \headdecl{sys/capability.h}
+ \funcdecl{int lsetxattr(const char *path, const char *name, const void
+ *value, size\_t size, int flags)}
- \funcdecl{int cap\_free(void *obj\_d)}
- Disalloca la memoria allocata per i dati delle \textit{capabilities}.
+ \funcdecl{int fsetxattr(int filedes, const char *name, const void *value,
+ size\_t size, int flags)}
+
+ Impostano il valore di un attributo esteso.
- \bodydesc{La funzione ritorna 0 in caso di successo e $-1$ in caso di
- errore, nel qual caso \var{errno} assumerà il valore \errval{EINVAL}.
- }
+ \bodydesc{Le funzioni restituiscono 0 in caso di successo, e $-1$ in caso di
+ errore, nel qual caso \var{errno} assumerà i valori:
+ \begin{errlist}
+ \item[\errcode{ENOATTR}] si è usato il flag \const{XATTR\_REPLACE} e
+ l'attributo richiesto non esiste.
+ \item[\errcode{EEXIST}] si è usato il flag \const{XATTR\_CREATE} ma
+ l'attributo esiste già.
+ \item[\errcode{ENOTSUP}] gli attributi estesi non sono supportati dal
+ filesystem o sono disabilitati.
+ \end{errlist}
+ Oltre a questi potranno essere restituiti tutti gli errori di \func{stat},
+ ed in particolare \errcode{EPERM} se non si hanno i permessi di accesso
+ all'attributo.
+}
\end{functions}
-La funzione permette di liberare la memoria allocata dalle altre funzioni
-della libreria sia per un \textit{capability state}, nel qual caso l'argomento
-dovrà essere un dato di tipo \type{cap\_t}, che per una descrizione testuale
-dello stesso,\footnote{cioè quanto ottenuto tramite la funzione
- \func{cap\_to\_text}.} nel qual caso l'argomento dovrà essere un dato di
-tipo \texttt{char *}. Per questo l'argomento \param{obj\_d} è dichiarato come
-\texttt{void *} e deve sempre corrispondere ad un puntatore ottenuto tramite
-le altre funzioni della libreria, altrimenti la funzione fallirà con un errore
-di \errval{EINVAL}.
+Le tre funzioni prendono come primo argomento un valore adeguato al loro
+scopo, usato in maniera del tutto identica a quanto visto in precedenza per le
+analoghe che leggono gli attributi estesi. Il secondo argomento \param{name}
+deve indicare, anche in questo caso con gli stessi criteri appena visti per le
+analoghe \func{getxattr}, \func{lgetxattr} e \func{fgetxattr}, il nome
+(completo di suffisso) dell'attributo su cui si vuole operare.
-Infine si può creare una copia di un \textit{capability state} ottenuto in
-precedenza tramite la funzione \funcd{cap\_dup}, il cui prototipo è:
-\begin{functions}
- \headdecl{sys/capability.h}
+Il valore che verrà assegnato all'attributo dovrà essere preparato nel buffer
+puntato da \param{value}, e la sua dimensione totale (in byte) sarà indicata
+dall'argomento \param{size}. Infine l'argomento \param{flag} consente di
+controllare le modalità di sovrascrittura dell'attributo esteso, esso può
+prendere due valori: con \const{XATTR\_REPLACE} si richiede che l'attributo
+esista, nel qual caso verrà sovrascritto, altrimenti si avrà errore, mentre
+con \const{XATTR\_CREATE} si richiede che l'attributo non esista, nel qual
+caso verrà creato, altrimenti si avrà errore ed il valore attuale non sarà
+modificato. Utilizzando per \param{flag} un valore nullo l'attributo verrà
+modificato se è già presente, o creato se non c'è.
- \funcdecl{cap\_t cap\_dup(cap\_t cap\_p)}
- Duplica un \textit{capability state} restituendone una copia.
+Le funzioni finora illustrate permettono di leggere o scrivere gli attributi
+estesi, ma sarebbe altrettanto utile poter vedere quali sono gli attributi
+presenti; a questo provvedono le funzioni \funcd{listxattr},
+\funcd{llistxattr} e \funcd{flistxattr} i cui prototipi sono:
+\begin{functions}
+ \headdecl{sys/types.h}
+ \headdecl{attr/xattr.h}
- \bodydesc{La funzione ritorna un valore non nullo in caso di successo e
- \macro{NULL} in caso di errore, nel qual caso \var{errno} potrà assumere i
- valori \errval{ENOMEM} o \errval{EINVAL}.
- }
-\end{functions}
+ \funcdecl{ssize\_t listxattr(const char *path, char *list, size\_t size)}
-La funzione crea una copia del \textit{capability state} posto all'indirizzo
-\param{cap\_p} che si è passato come argomento, restituendo il puntatore alla
-copia, che conterrà gli stessi valori delle \textit{capabilities} presenti
-nell'originale. La memoria necessaria viene allocata automaticamente dalla
-funzione. Una volta effettuata la copia i due \textit{capability state}
-potranno essere modificati in maniera completamente
-indipendente.\footnote{alla fine delle operazioni si ricordi però di
- disallocare anche la copia, oltre all'originale. }
+ \funcdecl{ssize\_t llistxattr(const char *path, char *list, size\_t size)}
-Una seconda classe di funzioni di servizio previste dall'interfaccia sono
-quelle per la gestione dei dati contenuti all'interno di un \textit{capability
- state}; la prima di queste è \funcd{cap\_clear}, il cui prototipo è:
-\begin{functions}
- \headdecl{sys/capability.h}
+ \funcdecl{ssize\_t flistxattr(int filedes, char *list, size\_t size)}
- \funcdecl{int cap\_clear(cap\_t cap\_p)}
- Inizializza un \textit{capability state} cancellando tutte le
- \textit{capabilities}.
+ Leggono la lista degli attributi estesi di un file.
- \bodydesc{La funzione ritorna 0 in caso di successo e $-1$ in caso di
- errore, nel qual caso \var{errno} assumerà il valore \errval{EINVAL}.
- }
-\end{functions}
-
-La funzione si limita ad azzerare tutte le \textit{capabilities} presenti nel
-\textit{capability state} all'indirizzo \param{cap\_p} passato come argomento,
-restituendo uno stato \textsl{vuoto}, analogo a quello che si ottiene nella
-creazione con \func{cap\_init}.
+ \bodydesc{Le funzioni restituiscono un intero positivo che indica la
+ dimensione della lista in caso di successo, e $-1$ in caso di errore, nel
+ qual caso \var{errno} assumerà i valori:
+ \begin{errlist}
+ \item[\errcode{ERANGE}] la dimensione \param{size} del buffer \param{value}
+ non è sufficiente per contenere il risultato.
+ \item[\errcode{ENOTSUP}] gli attributi estesi non sono supportati dal
+ filesystem o sono disabilitati.
+ \end{errlist}
+ Oltre a questi potranno essere restituiti tutti gli errori di \func{stat},
+ ed in particolare \errcode{EPERM} se non si hanno i permessi di accesso
+ all'attributo.
+}
+\end{functions}
-Per la gestione dei valori delle \textit{capabilities} presenti in un
-\textit{capability state} l'interfaccia prevede due funzioni,
-\funcd{cap\_get\_flag} e \funcd{cap\_set\_flag}, che permettono
-rispettivamente di leggere o impostare il valore di un flag delle
-\textit{capabilities}; i rispettivi prototipi sono:
+Come per le precedenti le tre funzioni leggono gli attributi rispettivamente
+di un file, un link simbolico o specificando un file descriptor, da
+specificare con il loro primo argomento. Gli altri due argomenti, identici per
+tutte e tre, indicano rispettivamente il puntatore \param{list} al buffer dove
+deve essere letta la lista e la dimensione \param{size} di quest'ultimo.
+
+La lista viene fornita come sequenza non ordinata dei nomi dei singoli
+attributi estesi (sempre comprensivi del prefisso della loro classe) ciascuno
+dei quali è terminato da un carattere nullo. I nomi sono inseriti nel buffer
+uno di seguito all'altro. Il valore di ritorno della funzione indica la
+dimensione totale della lista in byte.
+
+Come per le funzioni di lettura dei singoli attributi se le dimensioni del
+buffer non sono sufficienti si avrà un errore, ma è possibile ottenere dal
+valore di ritorno della funzione una stima della dimensione totale della lista
+usando per \param{size} un valore nullo.
+
+Infine per rimuovere semplicemente un attributo esteso, si ha a disposizione
+un ultimo gruppo di funzioni: \funcd{removexattr}, \funcd{lremovexattr} e
+\funcd{fremovexattr}; i rispettivi prototipi sono:
\begin{functions}
- \headdecl{sys/capability.h}
+ \headdecl{sys/types.h}
+ \headdecl{attr/xattr.h}
+
+ \funcdecl{int removexattr(const char *path, const char *name)}
- \funcdecl{int cap\_get\_flag(cap\_t cap\_p, cap\_value\_t cap, cap\_flag\_t
- flag, cap\_flag\_value\_t *value\_p)}
- Legge il valore di una \textit{capability}.
+ \funcdecl{int lremovexattr(const char *path, const char *name)}
- \funcdecl{int cap\_set\_flag(cap\_t cap\_p, cap\_flag\_t flag, int ncap,
- cap\_value\_t *caps, cap\_flag\_value\_t value)}
- Imposta il valore di una \textit{capability}.
+ \funcdecl{int fremovexattr(int filedes, const char *name)}
+
+
+ Rimuovono un attributo esteso di un file.
- \bodydesc{Le funzioni ritornano 0 in caso di successo e $-1$ in caso di
- errore, nel qual caso \var{errno} assumerà il valore \errval{EINVAL}.
+ \bodydesc{Le funzioni restituiscono 0 in caso di successo, e $-1$ in caso di
+ errore, nel qual caso \var{errno} assumerà i valori:
+ \begin{errlist}
+ \item[\errcode{ENOATTR}] l'attributo richiesto non esiste.
+ \item[\errcode{ENOTSUP}] gli attributi estesi non sono supportati dal
+ filesystem o sono disabilitati.
+ \end{errlist}
+ ed inoltre tutti gli errori di \func{stat}.
}
\end{functions}
-In entrambe le funzioni l'argomento \param{cap\_p} indica il puntatore al
-\textit{capability state} su cui operare, mentre l'argomento \param{flag}
-indica su quale dei tre insiemi illustrati a
-pag.~\pageref{sec:capabilities_set} si intende operare. Questi devono essere
-specificati con una variabile di tipo \type{cap\_flag\_t} che può assumere
-esclusivamente\footnote{si tratta in effetti di un tipo enumerato, come si può
- verificare dalla sua definizione che si trova in
- \texttt{/usr/include/sys/capability.h}.} uno dei valori illustrati in
-tab.~\ref{tab:cap_set_identifier}.
+Le tre funzioni rimuovono l'attributo esteso indicato dall'argomento
+\param{name} rispettivamente di un file, un link simbolico o specificando un
+file descriptor, da specificare con il loro primo argomento. Anche in questo
+caso l'argomento \param{name} deve essere specificato con le modalità già
+illustrate in precedenza per le altre funzioni relative agli attributi estesi.
-\begin{table}[htb]
- \centering
- \footnotesize
- \begin{tabular}[c]{|l|l|}
- \hline
- \textbf{Valore} & \textbf{Significato} \\
- \hline
- \hline
- \const{CAP\_EFFECTIVE} & Capacità dell'insieme \textsl{effettivo}.\\
- \const{CAP\_PERMITTED} & Capacità dell'insieme \textsl{permesso}.\\
- \const{CAP\_INHERITABLE}& Capacità dell'insieme \textsl{ereditabile}.\\
- \hline
- \end{tabular}
- \caption{Valori possibili per il tipo di dato \type{cap\_flag\_t} che
- identifica gli insiemi delle \textit{capabilities}.}
- \label{tab:cap_set_identifier}
-\end{table}
+\itindend{Extended~Attributes}
-La capacità che si intende controllare o impostare invece deve essere
-specificata attraverso una variabile di tipo \type{cap\_value\_t}, che può
-prendere come valore uno qualunque di quelli riportati in
-tab.~\ref{tab:proc_capabilities}, in questo caso però non è possibile
-combinare diversi valori in una maschera binaria, una variabile di tipo
-\type{cap\_value\_t} deve indicare una sola capacità.\footnote{nel file di
- header citato nella nota precedente il tipo \type{cap\_value\_t} è definito
- come \ctyp{int}, ma i valori validi sono soltanto quelli di
- tab.~\ref{tab:proc_capabilities}.}
-Infine lo stato di una capacità è descritto ad una variabile di tipo
-\type{cap\_flag\_value\_t}, che a sua volta può assumere soltanto
-uno\footnote{anche questo è un tipo enumerato.} dei valori di
-tab.~\ref{tab:cap_value_type}.
+\subsection{Le \textit{Access Control List}}
+\label{sec:file_ACL}
+
+% la documentazione di sistema è nei pacchetti libacl1-dev e acl
+% vedi anche http://www.suse.de/~agruen/acl/linux-acls/online/
+
+\itindbeg{Access~Control~List}
+
+Il modello classico dei permessi di Unix, per quanto funzionale ed efficiente,
+è comunque piuttosto limitato e per quanto possa aver coperto per lunghi anni
+le esigenze più comuni con un meccanismo semplice e potente, non è in grado di
+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 semplice.}
+
+Per questo motivo erano state progressivamente introdotte nelle varie versioni
+di Unix dei meccanismi di gestione dei permessi dei file più flessibili, nella
+forma delle cosiddette \textit{Access Control List} (indicate usualmente con
+la sigla ACL). Nello sforzo di standardizzare queste funzionalità era stato
+creato un gruppo di lavoro il cui scopo era estendere lo standard POSIX 1003
+attraverso due nuovi insiemi di specifiche, la POSIX 1003.1e per l'interfaccia
+di programmazione e la POSIX 1003.2c per i comandi di shell.
+
+Gli obiettivi erano però forse troppo ambizioni, e nel gennaio del 1998 i
+finanziamenti vennero ritirati senza che si fosse arrivati alla definizione di
+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 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
+\itindex{Extended~Attributes} \textit{Extended Attributes} (appena trattati in
+sez.~\ref{sec:file_xattr}), e fornire tutte le relative funzioni di gestione
+tramite una libreria, \texttt{libacl} che nasconde i dettagli implementativi
+delle ACL e presenta ai programmi una interfaccia che fa riferimento allo
+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 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}[c]{|l|l|}
+ \begin{tabular}{|l|p{8cm}|}
\hline
- \textbf{Valore} & \textbf{Significato} \\
+ \textbf{Tipo} & \textbf{Descrizione} \\
\hline
\hline
- \const{CAP\_CLEAR}& La capacità non è impostata.\\
- \const{CAP\_SET} & La capacità è impostata.\\
+ \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{Valori possibili per il tipo di dato \type{cap\_flag\_value\_t} che
- indica lo stato di una capacità.}
- \label{tab:cap_value_type}
+ \caption{Le costanti che identificano i tipi delle voci di una ACL.}
+ \label{tab:acl_tag_types}
\end{table}
-La funzione \func{cap\_get\_flag} legge lo stato della capacità indicata
-dall'argomento \param{cap} all'interno dell'insieme indicato dall'argomento
-\param{flag} e ne restituisce il valore nella variabile posta all'indirizzo
-puntato dall'argomento \param{value\_p}; è possibile cioè leggere soltanto uno
-stato di una capacità alla volta.
-
-La funzione \func{cap\_set\_flag} può invece impostare in una sola chiamata
-più \textit{capabilities}, anche se solo all'interno dello stesso insieme. Per
-questo motivo essa prende un vettore di valori di tipo \type{cap\_value\_t}
-nell'argomento \param{caps}, la cui dimensione viene specificata dall'argomento
-\param{ncap}. Il tipo di impostazione da eseguire (cancellazione o
-impostazione) viene indicato dall'argomento \param{value}.
-
-Per la visualizzazione dello stato delle \textit{capabilities} l'interfaccia
-prevede una funzione apposita, \funcd{cap\_to\_text}, il cui prototipo è:
-\begin{functions}
- \headdecl{sys/capability.h}
+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.
- \funcdecl{char * cap\_to\_text(cap\_t caps, ssize\_t * length\_p)}
+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.
- Genera una visualizzazione testuale delle \textit{capabilities}.
-
- \bodydesc{La funzione ritorna un puntatore alla stringa con la descrizione
- delle \textit{capabilities} in caso di successo e \val{NULL} in caso di
- errore, nel qual caso \var{errno} può assumere i valori \errval{EINVAL} o
- \errval{ENOMEM}.
- }
-\end{functions}
+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.
-La funzione ritorna l'indirizzo di una stringa contente la descrizione
-testuale del contenuto del \textit{capabilities state} \param{caps} passato
-come argomento, e, qualora l'argomento \param{length\_p} sia diverso da
-\val{NULL}, restituisce nella variabile intera da questo puntata la lunghezza
-della stringa. La stringa restituita viene allocata automaticamente dalla
-funzione e pertanto dovrà essere liberata con \func{cap\_free}.
+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}.}
-Fin quei abbiamo trattato solo le funzioni di servizio relative alla
-manipolazione dei \textit{capabilities state}; l'interfaccia di gestione
-prevede però anche le funzioni per la gestione delle \textit{capabilities}
-stesse. La prima di queste è \funcd{cap\_get\_proc} che consente la lettura
-delle \textit{capabilities} del processo corrente, il suo prototipo è:
+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 principale
+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/capability.h}
+ \headdecl{sys/types.h}
+ \headdecl{sys/acl.h}
+
+ \funcdecl{acl\_t acl\_init(int count)}
- \funcdecl{cap\_t cap\_get\_proc(void)}
- Legge le \textit{capabilities} del processo corrente.
+ Inizializza un'area di lavoro per una ACL di \param{count} voci.
- \bodydesc{La funzione ritorna un valore diverso da \val{NULL} in caso di
- successo e \val{NULL} in caso di errore, nel qual caso \var{errno} può
- assumere i valori \errval{EINVAL}, \errval{EPERM} o \errval{ENOMEM}. }
+ \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 legge il valore delle \textit{capabilities} associate al processo
-da cui viene invocata, restituendo il risultato tramite il puntatore ad un
-\textit{capabilities state} contenente tutti i dati che provvede ad allocare
-autonomamente e che di nuovo occorrerà liberare con \func{cap\_free} quando
-non sarà più utilizzato.
+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 \param{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}''.
-Se invece si vogliono leggere le \textit{capabilities} di un processo
-specifico occorre usare la funzione \funcd{capgetp}, il cui
-prototipo\footnote{su alcune pagine di manuale la funzione è descritta con un
- prototipo sbagliato, che prevede un valore di ritorno di tipo \type{cap\_t},
- ma il valore di ritorno è intero, come si può verificare anche dalla
- dichiarazione della stessa in \texttt{sys/capability.h}.} è:
+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 prototipo è:
\begin{functions}
- \headdecl{sys/capability.h}
+ \headdecl{sys/types.h}
+ \headdecl{sys/acl.h}
+
+ \funcdecl{int acl\_free(void * obj\_p)}
- \funcdecl{int capgetp(pid\_t pid, cap\_t cap\_d)}
- Legge le \textit{capabilities} del processo indicato da \param{pid}.
+ Disalloca la memoria riservata per i dati di una ACL.
- \bodydesc{La funzione ritorna 0 in caso di successo e $-1$ in caso di
- errore, nel qual caso \var{errno} può assumere i valori \errval{EINVAL},
- \errval{EPERM} o \errval{ENOMEM}.
- }
+ \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}
-%TODO controllare e correggere i codici di errore!!!
-La funzione legge il valore delle \textit{capabilities} del processo indicato
-con l'argomento \param{pid}, e restituisce il risultato nel
-\textit{capabilities state} posto all'indirizzo indicato con l'argomento
-\param{cap\_d}; a differenza della precedente in questo caso il
-\textit{capability state} deve essere stato creato in precedenza. Qualora il
-processo indicato non esista si avrà un errore di \errval{ESRCH}. Gli stessi
-valori possono essere letti direttamente nel filesystem \textit{proc}, nei
-file \texttt{/proc/<pid>/status}; ad esempio per \texttt{init} si otterrà
-qualcosa del tipo:
-\begin{Verbatim}
-...
-CapInh: 0000000000000000
-CapPrm: 00000000fffffeff
-CapEff: 00000000fffffeff
-...
-\end{Verbatim}
+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}.
-Infine per impostare le \textit{capabilities} del processo corrente (non
-esiste una funzione che permetta di cambiare le \textit{capabilities} di un
-altro processo) si deve usare la funzione \funcd{cap\_set\_proc}, il cui
-prototipo è:
+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/capability.h}
+ \headdecl{sys/types.h}
+ \headdecl{sys/acl.h}
+
+ \funcdecl{acl\_t acl\_dup(acl\_t acl)}
- \funcdecl{int cap\_set\_proc(cap\_t cap\_p)}
- Imposta le \textit{capabilities} del processo corrente.
+ Crea una copia della ACL \param{acl}.
- \bodydesc{La funzione ritorna 0 in caso di successo e $-1$ in caso di
- errore, nel qual caso \var{errno} può assumere i valori \errval{EINVAL},
- \errval{EPERM} o \errval{ENOMEM}.
- }
+ \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 modifica le \textit{capabilities} del processo corrente secondo
-quanto specificato con l'argomento \param{cap\_p}, posto che questo sia
-possibile nei termini spiegati in precedenza (non sarà ad esempio possibile
-impostare capacità non presenti nell'insieme di quelle permesse). In caso di
-successo i nuovi valori saranno effettivi al ritorno della funzione, in caso
-di fallimento invece lo stato delle capacità resterà invariato. Si tenga
-presente che \textsl{tutte} le capacità specificate tramite \param{cap\_p}
-devono essere permesse; se anche una sola non lo è la funzione fallirà, e per
-quanto appena detto, lo stato delle \textit{capabilities} non verrà modificato
-(neanche per le parti eventualmente permesse).
-
-Come esempio di utilizzo di queste funzioni nei sorgenti allegati alla guida
-si è distribuito il programma \texttt{getcap.c}, che consente di leggere le
-\textit{capabilities} del processo corrente\footnote{vale a dire di sé stesso,
- quando lo si lancia, il che può sembrare inutile, ma serve a mostrarci quali
- sono le \textit{capabilities} standard che ottiene un processo lanciato
- dalla riga di comando.} o tramite l'opzione \texttt{-p}, quelle di un
-processo qualunque il cui pid viene passato come parametro dell'opzione.
+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.
-\begin{figure}[htb]
- \footnotesize \centering
- \begin{minipage}[c]{15cm}
- \includecodesample{listati/getcap.c}
- \end{minipage}
- \normalsize
- \caption{Corpo principale del programma \texttt{getcap.c}.}
- \label{fig:proc_getcap}
-\end{figure}
-
-La sezione principale del programma è riportata in fig.~\ref{fig:proc_getcap},
-e si basa su una condizione sulla variabile \var{pid} che se si è usato
-l'opzione \texttt{-p} è impostata (nella sezione di gestione delle opzioni,
-che si è tralasciata) al valore del \textsl{pid} del processo di cui si vuole
-leggere le \textit{capabilities} e nulla altrimenti. Nel primo caso
-(\texttt{\small 1--6}) si utilizza direttamente (\texttt{\small 2})
-\func{cap\_get\_proc} per ottenere lo stato delle capacità del processo, nel
-secondo (\texttt{\small 7--14}) prima si inizializza (\texttt{\small 8}) uno
-stato vuoto e poi (\texttt{\small 9}) si legge il valore delle capacità del
-processo indicato.
-
-Il passo successivo è utilizzare (\texttt{\small 16}) \func{cap\_to\_text} per
-tradurre in una stringa lo stato, e poi (\texttt{\small 17}) stamparlo; infine
-(\texttt{\small 19--20}) si libera la memoria allocata dalle precedenti
-funzioni con \func{cap\_free} per poi ritornare dal ciclo principale della
-funzione.
-
-\itindend{capabilities}
-
-% TODO vedi http://lwn.net/Articles/198557/ e
-% http://www.madore.org/~david/linux/newcaps/
-% TODO documentare prctl ...
-
-\subsection{Gli attributi estesi}
-\label{sec:file_xattr}
+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)}
-\itindbeg{Extended~Attributes}
+ 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}.
-Nelle sezioni precedenti abbiamo trattato in dettaglio le varie informazioni
-che il sistema mantiene negli \itindex{inode} \textit{inode}, e le varie
-funzioni che permettono di modificarle. Si sarà notato come in realtà queste
-informazioni siano estremamente ridotte. Questo è dovuto al fatto che Unix
-origina negli anni '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
-trovare spazio nei dati classici mantenuti negli \itindex{inode}
-\textit{inode}.
+}
+\end{functions}
-Per risolvere questo problema alcuni sistemi unix-like (e fra questi anche
-Linux) hanno introdotto un meccanismo generico che consenta di associare delle
-informazioni ai singoli file,\footnote{l'uso più comune è quello della ACL,
- che tratteremo nella prossima sezione, ma si possono inserire anche altre
- informazioni.} detto \textit{Extended Attributes}. Gli \textsl{attributi
- estesi} non sono altro che delle coppie nome/valore che sono associate
-permanentemente ad un oggetto sul filesystem, analoghi di quello che sono le
-variabili di ambiente (vedi sez.~\ref{sec:proc_environ}) per un processo.
+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.
-Altri sistemi (come Solaris, MacOS e Windows) hanno adottato un meccanismo
-diverso in cui ad un file sono associati diversi flussi di dati, su cui
-possono essere mantenute ulteriori informazioni, che possono essere accedute
-con le normali operazioni di lettura e scrittura. Questi non vanno confusi con
-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, 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.
+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)}
-In Linux gli attributi estesi sono sempre associati al singolo \itindex{inode}
-\textit{inode} e l'accesso viene sempre eseguito in forma atomica, in lettura
-il valore corrente viene scritto su un buffer in memoria, mentre la scrittura
-prevede che ogni valore precedente sia sovrascritto.
+ 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}.
-Si tenga presente che non tutti i filesystem supportano gli \textit{Extended
- Attributes}, in particolare al momento della scrittura di queste dispense
-essi sono presenti solo su \textsl{ext2}, \textsl{ext3} e \textsl{XFS}.
-Inoltre a seconda della implementazione ci possono essere dei limiti sulla
-quantità di attributi che si possono utilizzare.\footnote{ad esempio nel caso
- di \textsl{ext2} ed \textsl{ext3} è richiesto che essi siano contenuti
- all'interno di un singolo blocco (pertanto con dimensioni massime pari a
- 1024, 2048 o 4096 byte a seconda delle dimensioni di quest'ultimo impostate
- in fase di creazione del filesystem), mentre con \textsl{XFS} non ci sono
- limiti ed i dati vengono memorizzati in maniera diversa (nell'\textit{inode}
- stesso, in un blocco a parte, o in una struttura ad albero dedicata) per
- mantenerne la scalabilità.} Infine lo spazio utilizzato per mantenere gli
-attributi estesi viene tenuto in conto per il calcolo delle quote di utente e
-gruppo proprietari del file.
+}
+\end{functions}
-Come meccanismo per mantenere informazioni aggiuntive associate al singolo
-file, gli \textit{Extended Attributes} possono avere usi anche molto diversi
-fra loro. Per poterli distinguere allora sono stati suddivisi in
-\textsl{classi}, a cui poter applicare requisiti diversi per l'accesso e la
-gestione. Per questo motivo il nome di un attributo deve essere sempre
-specificato nella forma \texttt{namespace.attribute}, dove \texttt{namespace}
-fa riferimento alla classe a cui l'attributo appartiene, mentre
-\texttt{attribute} è il nome ad esso assegnato. In tale forma il nome di un
-attributo esteso deve essere univoco. Al momento\footnote{della scrittura di
- questa sezione, kernel 2.6.23, ottobre 2007.} sono state definite le quattro
-classi di attributi riportate in tab.~\ref{tab:extended_attribute_class}.
+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|p{10cm}|}
+ \begin{tabular}{|l|l|}
\hline
- \textbf{Nome} & \textbf{Descrizione} \\
+ \textbf{Tipo} & \textbf{Descrizione} \\
\hline
\hline
- \texttt{security}&Gli \textit{extended security attributes}: vengono
- utilizzati dalle estensioni di sicurezza del kernel (i
- \itindex{Linux~Security~Modules} \textit{Linux
- Security Modules}), per le realizzazione di meccanismi
- evoluti di controllo di accesso come \index{SELinux}
- SELinux o le \textit{capabilities} dei file di
- sez.~\ref{sec:proc_capabilities}.\\
- \texttt{system} & Gli \textit{extended security attributes}: sono usati
- dal kernel per memorizzare dati di sistema associati ai
- file come le \itindex{Access~Control~List} ACL (vedi
- sez.~\ref{sec:file_ACL}) o le \itindex{capabilities}
- \textit{capabilities} (vedi
- sez.~\ref{sec:proc_capabilities}).\\
- \texttt{trusted}& I \textit{trusted extended attributes}: vengono
- utilizzati per poter realizzare in user space
- meccanismi che consentano di mantenere delle
- informazioni sui file che non devono essere accessibili
- ai processi ordinari.\\
- \texttt{user} & Gli \textit{extended user attributes}: utilizzati per
- mantenere informazioni aggiuntive sui file (come il
- \textit{mime-type}, la codifica dei caratteri o del
- file) accessibili dagli utenti.\\
+ \const{ACL\_TYPE\_ACCESS} & indica una ACL di accesso.\\
+ \const{ACL\_TYPE\_DEFAULT}& indica una ACL di default.\\
\hline
\end{tabular}
- \caption{I nomi utilizzati valore di \texttt{namespace} per distinguere le
- varie classi di \textit{Extended Attributes}.}
- \label{tab:extended_attribute_class}
+ \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 sufficienti 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.
-Dato che uno degli usi degli \textit{Extended Attributes} è quello che li
-impiega per realizzare delle estensioni (come le \itindex{Access~Control~List}
-ACL, \index{SELinux} SELinux, ecc.) al tradizionale meccanismo dei controlli
-di accesso di Unix, l'accesso ai loro valori viene regolato in maniera diversa
-a seconda sia della loro classe sia di quali, fra le estensioni che li
-utilizzano, sono poste in uso. In particolare, per ciascuna delle classi
-riportate in tab.~\ref{tab:extended_attribute_class}, si hanno i seguenti
-casi:
-\begin{basedescript}{\desclabelwidth{1.7cm}\desclabelstyle{\nextlinelabel}}
-\item[\texttt{security}] L'accesso agli \textit{extended security attributes}
- dipende dalle politiche di sicurezza stabilite da loro stessi tramite
- l'utilizzo di un sistema di controllo basato sui
- \itindex{Linux~Security~Modules} \textit{Linux Security Modules} (ad esempio
- \index{SELinux} SELinux). Pertanto l'accesso in lettura o scrittura dipende
- dalle politiche di sicurezza implementate all'interno dal modulo di
- sicurezza che si sta utilizzando al momento (ciascuno avrà le sue). Se non è
- stato caricato nessun modulo di sicurezza l'accesso in lettura sarà
- consentito a tutti i processi, mentre quello in scrittura solo ai processi
- con privilegi amministrativi dotati della \index{capabilities}
- \textit{capability} \const{CAP\_SYS\_ADMIN}.
+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)}
-\item[\texttt{system}] Anche l'accesso agli \textit{extended system
- attributes} dipende dalle politiche di accesso che il kernel realizza
- anche utilizzando gli stessi valori in essi contenuti. Ad esempio nel caso
- delle \itindex{Access~Control~List} ACL l'accesso è consentito in lettura ai
- processi che hanno la capacità di eseguire una ricerca sul file (cioè hanno
- il permesso di lettura sulla directory che contiene il file) ed in scrittura
- al proprietario del file o ai processi dotati della \textit{capability}
- \index{capabilities} \const{CAP\_FOWNER}.\footnote{vale a dire una politica
- di accesso analoga a quella impiegata per gli ordinari permessi dei file.}
+ 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}
-\item[\texttt{trusted}] L'accesso ai \textit{trusted extended attributes}, sia
- per la lettura che per la scrittura, è consentito soltanto ai processi con
- privilegi amministrativi dotati della \index{capabilities}
- \textit{capability} \const{CAP\_SYS\_ADMIN}. In questo modo si possono
- utilizzare questi attributi per realizzare in user space dei meccanismi di
- controllo che accedono ad informazioni non disponibili ai processi ordinari.
+}
+\end{functions}
-\item[\texttt{user}] L'accesso agli \textit{extended user attributes} è
- regolato dai normali permessi dei file: occorre avere il permesso di lettura
- per leggerli e quello di scrittura per scriverli o modificarli. Dato l'uso
- di questi attributi si è scelto di applicare al loro accesso gli stessi
- criteri che si usano per l'accesso al contenuto dei file (o delle directory)
- cui essi fanno riferimento. Questa scelta vale però soltanto per i file e le
- directory ordinarie, se valesse in generale infatti si avrebbe un serio
- problema di sicurezza dato che esistono diversi oggetti sul filesystem per i
- quali è normale avere avere il permesso di scrittura consentito a tutti gli
- utenti, come i link simbolici, o alcuni \index{file!di~dispositivo} file di
- dispositivo come \texttt{/dev/null}. Se fosse possibile usare su di essi gli
- \textit{extended user attributes} un utente qualunque potrebbe inserirvi
- dati a piacere.\footnote{la cosa è stata notata su XFS, dove questo
- comportamento permetteva, non essendovi limiti sullo spazio occupabile
- dagli \textit{Extended Attributes}, di bloccare il sistema riempiendo il
- disco.}
+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 semantica del controllo di accesso indicata inoltre non avrebbe alcun
- senso al di fuori di file e directory: i permessi di lettura e scrittura per
- un \index{file!di~dispositivo} file di dispositivo attengono alle capacità
- di accesso al dispositivo sottostante,\footnote{motivo per cui si può
- formattare un disco anche se \texttt{/dev} è su un filesystem in sola
- lettura.} mentre per i link simbolici questi vengono semplicemente
- ignorati: in nessuno dei due casi hanno a che fare con il contenuto del
- file, e nella discussione relativa all'uso degli \textit{extended user
- attributes} nessuno è mai stato capace di indicare una qualche forma
- sensata di utilizzo degli stessi per link simbolici o
- \index{file!di~dispositivo} file di dispositivo, e neanche per le fifo o i
- socket. Per questo motivo essi sono stati completamente disabilitati per
- tutto ciò che non sia un file regolare o una directory.\footnote{si può
- verificare la semantica adottata consultando il file \texttt{fs/xattr.c}
- dei sorgenti del kernel.} Inoltre per le directory è stata introdotta una
- ulteriore restrizione, dovuta di nuovo alla presenza ordinaria di permessi
- di scrittura completi su directory come \texttt{/tmp}. Per questo motivo,
- per evitare eventuali abusi, se una directory ha lo \itindex{sticky~bit}
- \textit{sticky bit} attivo sarà consentito scrivere i suoi \textit{extended
- user attributes} soltanto se si è proprietari della stessa, o si hanno i
- privilegi amministrativi della capability \index{capabilities}
- \const{CAP\_FOWNER}.
-\end{basedescript}
+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} e
+\texttt{group} e indica l'utente o il gruppo a cui la voce si riferisce; i
+permessi sono espressi con una tripletta di lettere analoga a quella usata per
+i permessi dei file.\footnote{vale a dire \texttt{r} per il permesso di
+ lettura, \texttt{w} per il permesso di scrittura, \texttt{x} per il permesso
+ di esecuzione (scritti in quest'ordine) e \texttt{-} per l'assenza del
+ permesso.}
-Le funzioni per la gestione degli attributi estesi, come altre funzioni di
-gestione avanzate specifiche di Linux, non fanno parte delle \acr{glibc}, e
-sono fornite da una apposita libreria, \texttt{libattr}, che deve essere
-installata a parte;\footnote{la versione corrente della libreria è
- \texttt{libattr1}.} pertanto se un programma le utilizza si dovrà indicare
-esplicitamente l'uso della suddetta libreria invocando il compilatore con
-l'opzione \texttt{-lattr}.
+Va precisato che i due tipi \texttt{user} e \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, ed in genere si scrivono per prima delle altre.
+Il significato delle voci di tipo \texttt{mask} e \texttt{mark} è evidente. In
+questa forma si possono anche inserire dei commenti precedendoli con il
+carattere ``\texttt{\#}''.
-Per poter leggere gli attributi estesi sono disponibili tre diverse funzioni,
-\funcd{getxattr}, \funcd{lgetxattr} e \funcd{fgetxattr}, che consentono
-rispettivamente di richiedere gli attributi relativi a un file, a un link
-simbolico e ad un file descriptor; i rispettivi prototipi sono:
+La forma breve prevede invece la scrittura delle singole voci su una riga,
+separate da virgole; come specificatori del tipo di voce si possono usare le
+iniziali dei valori usati nella forma estesa (cioè ``\texttt{u}'',
+``\texttt{g}'', ``\texttt{o}'' e ``\texttt{m}''), mentre le altri parte della
+voce sono le stesse. In questo caso non sono consentiti permessi.
+
+Per la conversione inversa, che consente di ottenere la rappresentazione
+testuale di una ACL, sono invece disponibili due funzioni, la prima delle due,
+di uso più immediato, è \funcd{acl\_to\_text}, il cui prototipo è:
\begin{functions}
\headdecl{sys/types.h}
- \headdecl{attr/xattr.h}
+ \headdecl{sys/acl.h}
- \funcdecl{ssize\_t getxattr(const char *path, const char *name, void
- *value, size\_t size)}
-
- \funcdecl{ssize\_t lgetxattr(const char *path, const char *name, void
- *value, size\_t size)}
-
- \funcdecl{ssize\_t fgetxattr(int filedes, const char *name, void *value,
- size\_t size)}
+ \funcdecl{char * acl\_to\_text(acl\_t acl, ssize\_t *len\_p)}
- Le funzioni leggono il valore di un attributo esteso.
+ Produce la rappresentazione testuale di una ACL.
- \bodydesc{Le funzioni restituiscono un intero positivo che indica la
- dimensione dell'attributo richiesto in caso di successo, e $-1$ in caso di
- errore, nel qual caso \var{errno} assumerà i valori:
+ \bodydesc{La funzione restituisce il puntatore ad una stringa con la
+ rappresentazione testuale della ACL 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{ENOATTR}] l'attributo richiesto non esiste.
- \item[\errcode{ERANGE}] la dimensione \param{size} del buffer \param{value}
- non è sufficiente per contenere il risultato.
- \item[\errcode{ENOTSUP}] gli attributi estesi non sono supportati dal
- filesystem o sono disabilitati.
+ \item[\errcode{ENOMEM}] non c'è memoria sufficiente per allocare i dati.
+ \item[\errcode{EINVAL}] la ACL indicata da \param{acl} non è valida.
\end{errlist}
- e tutti gli errori di \func{stat}, come \errcode{EPERM} se non si hanno i
- permessi di accesso all'attributo. }
-\end{functions}
-
-Le funzioni \func{getxattr} e \func{lgetxattr} prendono come primo argomento
-un pathname che indica il file di cui si vuole richiedere un attributo, la
-sola differenza è che la seconda, se il pathname indica un link simbolico,
-restituisce gli attributi di quest'ultimo e non quelli del file a cui esso fa
-riferimento. La funzione \func{fgetxattr} prende invece come primo argomento
-un numero di file descriptor, e richiede gli attributi del file ad esso
-associato.
-Tutte e tre le funzioni richiedono di specificare nell'argomento \param{name}
-il nome dell'attributo di cui si vuole ottenere il valore. Il nome deve essere
-indicato comprensivo di prefisso del \textit{namespace} cui appartiene (uno
-dei valori di tab.~\ref{tab:extended_attribute_class}) nella forma
-\texttt{namespace.attributename}, come stringa terminata da un carattere NUL.
-Il suo valore verrà restituito nel buffer puntato dall'argomento \param{value}
-per una dimensione massima di \param{size} byte;\footnote{gli attributi estesi
- possono essere costituiti arbitrariamente da dati testuali o binari.} se
-quest'ultima non è sufficiente si avrà un errore di \errcode{ERANGE}.
+}
+\end{functions}
-Per evitare di dover indovinare la dimensione di un attributo per tentativi si
-può eseguire una interrogazione utilizzando un valore nullo per \param{size};
-in questo caso non verrà letto nessun dato, ma verrà restituito come valore di
-ritorno della funzione chiamata la dimensione totale dell'attributo esteso
-richiesto, che si potrà usare come stima per allocare un buffer di dimensioni
-sufficienti.\footnote{si parla di stima perché anche se le funzioni
- restituiscono la dimensione esatta dell'attributo al momento in cui sono
- eseguite, questa potrebbe essere modificata in qualunque momento da un
- successivo accesso eseguito da un altro processo.}
+La funzione restituisce il puntatore ad una stringa terminata da NUL
+contenente la rappresentazione in forma estesa della ACL passata come
+argomento, ed alloca automaticamente la memoria necessaria. Questa dovrà poi
+essere liberata, quando non più necessaria, con \func{acl\_free}. Se
+nell'argomento \param{len\_p} si passa un valore puntatore ad una variabile
+intera in questa verrà restituita la dimensione della stringa con la
+rappresentazione testuale (non comprendente il carattere nullo finale).
-Un secondo gruppo di funzioni è quello che consente di impostare il valore di
-un attributo esteso, queste sono \funcd{setxattr}, \funcd{lsetxattr} e
-\funcd{fsetxattr}, e consentono di operare rispettivamente su un file, su un
-link simbolico o specificando un file descriptor; i loro prototipi sono:
+La seconda funzione, \funcd{acl\_to\_any\_text}, permette di controllare con
+dovizia di dettagli la generazione della stringa contenente la
+rappresentazione testuale della ACL, il suo prototipo è:
\begin{functions}
\headdecl{sys/types.h}
- \headdecl{attr/xattr.h}
+ \headdecl{sys/acl.h}
- \funcdecl{int setxattr(const char *path, const char *name, const void
- *value, size\_t size, int flags)}
-
- \funcdecl{int lsetxattr(const char *path, const char *name, const void
- *value, size\_t size, int flags)}
+ \funcdecl{char * acl\_to\_any\_text(acl\_t acl, const char *prefix, char
+ separator, int options)}
- \funcdecl{int fsetxattr(int filedes, const char *name, const void *value,
- size\_t size, int flags)}
+ Produce la rappresentazione testuale di una ACL.
- Impostano il valore di un attributo esteso.
-
- \bodydesc{Le funzioni restituiscono 0 in caso di successo, e $-1$ in caso di
- errore, nel qual caso \var{errno} assumerà i valori:
+ \bodydesc{La funzione restituisce il puntatore ad una stringa con la
+ rappresentazione testuale della ACL in caso di successo e \code{NULL} in
+ caso di errore, nel qual caso \var{errno} assumerà uno dei valori:
\begin{errlist}
- \item[\errcode{ENOATTR}] si è usato il flag \const{XATTR\_REPLACE} e
- l'attributo richiesto non esiste.
- \item[\errcode{EEXIST}] si è usato il flag \const{XATTR\_CREATE} ma
- l'attributo esiste già.
- \item[\errcode{ENOTSUP}] gli attributi estesi non sono supportati dal
- filesystem o sono disabilitati.
+ \item[\errcode{ENOMEM}] non c'è memoria sufficiente per allocare i dati.
+ \item[\errcode{EINVAL}] la ACL indicata da \param{acl} non è valida.
\end{errlist}
- Oltre a questi potranno essere restituiti tutti gli errori di \func{stat},
- ed in particolare \errcode{EPERM} se non si hanno i permessi di accesso
- all'attributo.
+
}
\end{functions}
-Le tre funzioni prendono come primo argomento un valore adeguato al loro
-scopo, usato in maniera del tutto identica a quanto visto in precedenza per le
-analoghe che leggono gli attributi estesi. Il secondo argomento \param{name}
-deve indicare, anche in questo caso con gli stessi criteri appena visti per le
-analoghe \func{getxattr}, \func{lgetxattr} e \func{fgetxattr}, il nome
-(completo di suffisso) dell'attributo su cui si vuole operare.
+La funzione converte in formato testo la ACL indicata dall'argomento
+\param{acl}, usando il carattere \param{separator} come separatore delle
+singole voci; se l'argomento \param{prefix} non è nullo la stringa da esso
+indicata viene utilizzata come prefisso per le singole voci.
-Il valore che verrà assegnato all'attributo dovrà essere preparato nel buffer
-puntato da \param{value}, e la sua dimensione totale (in byte) sarà indicata
-dall'argomento \param{size}. Infine l'argomento \param{flag} consente di
-controllare le modalità di sovrascrittura dell'attributo esteso, esso può
-prendere due valori: con \const{XATTR\_REPLACE} si richiede che l'attributo
-esista, nel qual caso verrà sovrascritto, altrimenti si avrà errore, mentre
-con \const{XATTR\_CREATE} si richiede che l'attributo non esista, nel qual
-caso verrà creato, altrimenti si avrà errore ed il valore attuale non sarà
-modificato. Utilizzando per \param{flag} un valore nullo l'attributo verrà
-modificato se è già presente, o creato se non c'è.
+L'ultimo argomento, \param{options}, consente di controllare la modalità con
+cui viene generata la rappresentazione testuale. Un valore nullo fa si che
+vengano usati gli identificatori standard \texttt{user}, \texttt{group},
+\texttt{other} e \texttt{mask} con i nomi di utenti e gruppi risolti rispetto
+ai loro valori numerici. Altrimenti si può specificare un valore in forma di
+maschera binaria, da ottenere con un OR aritmetico dei valori riportati in
+tab.~\ref{tab:acl_to_text_options}.
-Le funzioni finora illustrate permettono di leggere o scrivere gli attributi
-estesi, ma sarebbe altrettanto utile poter vedere quali sono gli attributi
-presenti; a questo provvedono le funzioni \funcd{listxattr},
-\funcd{llistxattr} e \funcd{flistxattr} i cui prototipi sono:
+\begin{table}[htb]
+ \centering
+ \footnotesize
+ \begin{tabular}{|l|p{8cm}|}
+ \hline
+ \textbf{Tipo} & \textbf{Descrizione} \\
+ \hline
+ \hline
+ \const{TEXT\_ABBREVIATE} & stampa le voci in forma abbreviata.\\
+ \const{TEXT\_NUMERIC\_IDS} & non effettua la risoluzione numerica di
+ user-ID e group-ID.\\
+ \const{TEXT\_SOME\_EFFECTIVE}& per ciascuna voce che contiene permessi che
+ vengono eliminati dalla \const{ACL\_MASK}
+ viene generato un commento con i permessi
+ effettivamente risultanti; il commento è
+ separato con un tabulatore.\\
+ \const{TEXT\_ALL\_EFFECTIVE} & viene generato un commento con i permessi
+ effettivi per ciascuna voce che contiene
+ permessi citati nella \const{ACL\_MASK},
+ anche quando questi non vengono modificati
+ da essa; il commento è separato con un
+ tabulatore.\\
+ \const{TEXT\_SMART\_INDENT} & da usare in combinazione con le precedenti
+ \const{TEXT\_SOME\_EFFECTIVE} e
+ \const{TEXT\_ALL\_EFFECTIVE} aumenta
+ automaticamente il numero di spaziatori
+ prima degli eventuali commenti in modo da
+ mantenerli allineati.\\
+ \hline
+ \end{tabular}
+ \caption{Possibili valori per l'argomento \param{options} di
+ \func{acl\_to\_any\_text}.}
+ \label{tab:acl_to_text_options}
+\end{table}
+
+Come per \func{acl\_to\_text} anche in questo caso il buffer contenente la
+rappresentazione testuale dell'ACL, di cui la funzione restituisce
+l'indirizzo, viene allocato automaticamente, e dovrà essere esplicitamente
+disallocato con una chiamata ad \func{acl\_free}. Si tenga presente infine che
+questa funzione è una estensione specifica di Linux, e non è presente nella
+bozza dello standard POSIX.1e.
+
+Per quanto utile per la visualizzazione o l'impostazione da comando delle ACL,
+la forma testuale non è la più efficiente per poter memorizzare i dati
+relativi ad una ACL, ad esempio quando si vuole eseguirne una copia a scopo di
+archiviazione. Per questo è stata prevista la possibilità di utilizzare una
+rappresentazione delle ACL in una apposita forma binaria contigua e
+persistente. È così possibile copiare il valore di una ACL in un buffer e da
+questa rappresentazione tornare indietro e generare una ACL.
+
+Lo standard POSIX.1e prevede a tale scopo tre funzioni, la prima e più
+semplice è \funcd{acl\_size}, che consente di ottenere la dimensione che avrà
+la citata rappresentazione binaria, in modo da poter allocare per essa un
+buffer di dimensione sufficiente, il suo prototipo è:
\begin{functions}
\headdecl{sys/types.h}
- \headdecl{attr/xattr.h}
+ \headdecl{sys/acl.h}
- \funcdecl{ssize\_t listxattr(const char *path, char *list, size\_t size)}
+ \funcdecl{ssize\_t acl\_size(acl\_t acl)}
- \funcdecl{ssize\_t llistxattr(const char *path, char *list, size\_t size)}
-
- \funcdecl{ssize\_t flistxattr(int filedes, char *list, size\_t size)}
+ Determina la dimensione della rappresentazione binaria di una ACL.
- Leggono la lista degli attributi estesi di un file.
-
- \bodydesc{Le funzioni restituiscono un intero positivo che indica la
- dimensione della lista in caso di successo, e $-1$ in caso di errore, nel
- qual caso \var{errno} assumerà i valori:
+ \bodydesc{La funzione restituisce in caso di successo la dimensione in byte
+ della rappresentazione binaria della ACL indicata da \param{acl} e $-1$ in
+ caso di errore, nel qual caso \var{errno} assumerà uno dei valori:
\begin{errlist}
- \item[\errcode{ERANGE}] la dimensione \param{size} del buffer \param{value}
- non è sufficiente per contenere il risultato.
- \item[\errcode{ENOTSUP}] gli attributi estesi non sono supportati dal
- filesystem o sono disabilitati.
+ \item[\errcode{EINVAL}] la ACL indicata da \param{acl} non è valida.
\end{errlist}
- Oltre a questi potranno essere restituiti tutti gli errori di \func{stat},
- ed in particolare \errcode{EPERM} se non si hanno i permessi di accesso
- all'attributo.
+
}
\end{functions}
-Come per le precedenti le tre funzioni leggono gli attributi rispettivamente
-di un file, un link simbolico o specificando un file descriptor, da
-specificare con il loro primo argomento. Gli altri due argomenti, identici per
-tutte e tre, indicano rispettivamente il puntatore \param{list} al buffer dove
-deve essere letta la lista e la dimensione \param{size} di quest'ultimo.
+Prima di effettuare la lettura della rappresentazione binaria è sempre
+necessario allocare un buffer di dimensione sufficiente a contenerla, pertanto
+prima si dovrà far ricorso a \funcd{acl\_size} per ottenere tale dimensione e
+poi allocare il buffer con una delle funzioni di
+sez.~\ref{sec:proc_mem_alloc}. Una volta terminato l'uso della
+rappresentazione binaria, il buffer dovrà essere esplicitamente disallocato.
-La lista viene fornita come sequenza non ordinata dei nomi dei singoli
-attributi estesi (sempre comprensivi del prefisso della loro classe) ciascuno
-dei quali è terminato da un carattere nullo. I nomi sono inseriti nel buffer
-uno di seguito all'altro. Il valore di ritorno della funzione indica la
-dimensione totale della lista in byte.
+La funzione che consente di leggere la rappresentazione binaria di una ACL è
+\funcd{acl\_copy\_ext}, il cui prototipo è:
+\begin{functions}
+ \headdecl{sys/types.h}
+ \headdecl{sys/acl.h}
+
+ \funcdecl{ssize\_t acl\_copy\_ext(void *buf\_p, acl\_t acl, ssize\_t size)}
-Come per le funzioni di lettura dei singoli attributi se le dimensioni del
-buffer non sono sufficienti si avrà un errore, ma è possibile ottenere dal
-valore di ritorno della funzione una stima della dimensione totale della lista
-usando per \param{size} un valore nullo.
+ Ottiene la rappresentazione binaria di una ACL.
-Infine per rimuovere semplicemente un attributo esteso, si ha a disposizione
-un ultimo gruppo di funzioni: \funcd{removexattr}, \funcd{lremovexattr} e
-\funcd{fremovexattr}; i rispettivi prototipi sono:
+ \bodydesc{La funzione restituisce in caso di successo la dimensione in byte
+ della rappresentazione binaria della ACL indicata da \param{acl} e $-1$ in
+ caso di errore, nel qual caso \var{errno} assumerà uno dei valori:
+ \begin{errlist}
+ \item[\errcode{EINVAL}] la ACL indicata da \param{acl} non è valida o
+ \param{size} è negativo o nullo.
+ \item[\errcode{ERANGE}] il valore di \param{size} è più piccolo della
+ dimensione della rappresentazione della ACL.
+ \end{errlist}
+
+}
+\end{functions}
+
+La funzione salverà la rappresentazione binaria della ACL indicata da
+\param{acl} sul buffer posto all'indirizzo \param{buf\_p} e lungo \param{size}
+byte, restituendo la dimensione della stessa come valore di ritorno. Qualora
+la dimensione della rappresentazione ecceda il valore di \param{size} la
+funzione fallirà con un errore di \errcode{ERANGE}. La funzione non ha nessun
+effetto sulla ACL indicata da \param{acl}.
+
+Viceversa se si vuole ripristinare una ACL a partire dalla rappresentazione
+binaria della stessa disponibile in un buffer si potrà usare la funzione
+\funcd{acl\_copy\_int}, il cui prototipo è:
\begin{functions}
\headdecl{sys/types.h}
- \headdecl{attr/xattr.h}
+ \headdecl{sys/acl.h}
- \funcdecl{int removexattr(const char *path, const char *name)}
+ \funcdecl{ssize\_t acl\_copy\_int(const void *buf\_p)}
- \funcdecl{int lremovexattr(const char *path, const char *name)}
+ Ripristina la rappresentazione binaria di una ACL.
- \funcdecl{int fremovexattr(int filedes, const char *name)}
+ \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}] il buffer all'indirizzo \param{buf\_p} non contiene
+ una rappresentazione corretta di una ACL.
+ \item[\errcode{ENOMEM}] non c'è memoria sufficiente per allocare un oggetto
+ \type{acl\_t} per la ACL richiesta.
+ \end{errlist}
+}
+\end{functions}
- Rimuovono un attributo esteso di un file.
+La funzione in caso di successo alloca autonomamente un oggetto di tipo
+\type{acl\_t} che viene restituito come valore di ritorno con il contenuto
+della ACL rappresentata dai dati contenuti nel buffer puntato da
+\param{buf\_p}. Si ricordi che come per le precedenti funzioni l'oggetto
+\type{acl\_t} dovrà essere disallocato esplicitamente al termine del suo
+utilizzo.
+
+Una volta che si disponga della ACL desiderata, questa potrà essere impostata
+su un file o una directory. Per impostare una ACL sono disponibili due
+funzioni; la prima è \funcd{acl\_set\_file}, che opera sia su file che su
+directory, ed il cui prototipo è:
+\begin{functions}
+ \headdecl{sys/types.h}
+ \headdecl{sys/acl.h}
- \bodydesc{Le funzioni restituiscono 0 in caso di successo, e $-1$ in caso di
- errore, nel qual caso \var{errno} assumerà i valori:
+ \funcdecl{int acl\_set\_file(const char *path, acl\_type\_t type, acl\_t
+ acl)}
+
+ Imposta una ACL su un file o una directory.
+
+ \bodydesc{La funzione restituisce $0$ in caso di successo e $-1$ in caso di
+ errore, nel qual caso \var{errno} assumerà uno dei valori:
\begin{errlist}
- \item[\errcode{ENOATTR}] l'attributo richiesto non esiste.
- \item[\errcode{ENOTSUP}] gli attributi estesi non sono supportati dal
- filesystem o sono disabilitati.
+ \item[\errcode{EACCES}] o un generico errore di accesso a \param{path} o il
+ valore di \param{type} specifica una ACL il cui tipo non può essere
+ assegnato a \param{path}.
+ \item[\errcode{EINVAL}] o \param{acl} non è una ACL valida, o \param{type}
+ ha in valore non corretto.
+ \item[\errcode{ENOSPC}] non c'è spazio disco sufficiente per contenere i
+ dati aggiuntivi della ACL.
+ \item[\errcode{ENOTSUP}] si è cercato di impostare una ACL su un file
+ contenuto in un filesystem che non supporta le ACL.
\end{errlist}
- ed inoltre tutti gli errori di \func{stat}.
+ ed inoltre \errval{ENOENT}, \errval{ENOTDIR}, \errval{ENAMETOOLONG},
+ \errval{EROFS}, \errval{EPERM}.
}
\end{functions}
-Le tre funzioni rimuovono l'attributo esteso indicato dall'argomento
-\param{name} rispettivamente di un file, un link simbolico o specificando un
-file descriptor, da specificare con il loro primo argomento. Anche in questo
-caso l'argomento \param{name} deve essere specificato con le modalità già
-illustrate in precedenza per le altre funzioni relative agli attributi estesi.
+La funzione consente di assegnare la ACL contenuta in \param{acl} al file o
+alla directory indicate dal pathname \param{path}, mentre con \param{type} si
+indica il tipo di ACL utilizzando le costanti di tab.~\ref{tab:acl_type}, ma
+si tenga presente che le ACL di default possono essere solo impostate
+qualora \param{path} indichi una directory. Inoltre perché la funzione abbia
+successo la ACL dovrà essere valida, e contenere tutti le voci necessarie,
+unica eccezione è quella in cui si specifica una ACL vuota per cancellare la
+ACL di default associata a \func{path}.\footnote{questo però è una estensione
+ della implementazione delle ACL di Linux, la bozza di standard POSIX.1e
+ prevedeva l'uso della apposita funzione \funcd{acl\_delete\_def\_file}, che
+ prende come unico argomento il pathname della directory di cui si vuole
+ cancellare l'ACL di default, per i dettagli si ricorra alla pagina di
+ manuale.} La seconda funzione che consente di impostare una ACL è
+\funcd{acl\_set\_fd}, ed il suo prototipo è:
+\begin{functions}
+ \headdecl{sys/types.h}
+ \headdecl{sys/acl.h}
+
+ \funcdecl{int acl\_set\_fd(int fd, acl\_t acl)}
-\itindend{Extended~Attributes}
+ Imposta una ACL su un file descriptor.
+ \bodydesc{La funzione restituisce $0$ in caso di successo e $-1$ in caso di
+ errore, nel qual caso \var{errno} assumerà uno dei valori:
+ \begin{errlist}
+ \item[\errcode{EBADF}].
+ \item[\errcode{EINVAL}] o \param{acl} non è una ACL valida, o \param{type}
+ ha in valore non corretto.
+ \item[\errcode{ENOSPC}] non c'è spazio disco sufficiente per contenere i
+ dati aggiuntivi della ACL.
+ \item[\errcode{ENOTSUP}] si è cercato di impostare una ACL su un file
+ contenuto in un filesystem che non supporta le ACL.
+ \end{errlist}
+ ed inoltre \errval{EBADF}, \errval{EROFS}, \errval{EPERM}.
+}
+\end{functions}
-\subsection{Le \textit{Access Control List}}
-\label{sec:file_ACL}
+La funzione è del tutto è analoga a \funcd{acl\_set\_file} ma opera
+esclusivamente sui file identificati tramite un file descriptor. Non dovendo
+avere a che fare con directory (e con la conseguente possibilità di avere una
+ACL di default) la funzione non necessita che si specifichi il tipo di ACL,
+che sarà sempre di accesso, e prende come unico argomento, a parte il file
+descriptor, la ACL da impostare.
-% la documentazione di sistema è nei pacchetti libacl1-dev e acl
-% vedi anche http://www.suse.de/~agruen/acl/linux-acls/online/
+Le funzioni viste finora operano a livello di una intera ACL, eseguendo in una
+sola volta tutte le operazioni relative a tutte le voci in essa contenuta. In
+generale è possibile modificare un singolo valore all'interno di una singola
+voce direttamente con le funzioni previste dallo standard POSIX.1e. Queste
+funzioni però sono alquanto macchinose da utilizzare per cui è molto più
+semplice operare direttamente sulla rappresentazione testuale. Questo è il
+motivo per non tratteremo nei dettagli dette funzioni, fornendone solo una
+descrizione sommaria; chi fosse interessato potrà ricorrere alle pagina di
+manuale.
-\itindbeg{Access~Control~List}
+Se si vuole operare direttamente sui contenuti di un oggetto di tipo
+\type{acl\_t} infatti occorre fare riferimento alle singole voci tramite gli
+opportuni puntatori di tipo \type{acl\_entry\_t}, che possono essere ottenuti
+dalla funzione \funcd{acl\_get\_entry} (per una voce esistente) o dalla
+funzione \funcd{acl\_create\_entry} per una voce da aggiungere. Nel caso della
+prima funzione si potrà poi ripetere la lettura per ottenere i puntatori alle
+singole voci successive alla prima.
-Il modello classico dei permessi di Unix, per quanto funzionale ed efficiente,
-è comunque piuttosto limitato e per quanto possa aver coperto per lunghi anni
-le esigenze più comuni con un meccanismo semplice e potente, non è in grado di
-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 semplice.}
+Una volta ottenuti detti puntatori si potrà operare sui contenuti delle singole
+voci; con le funzioni \funcd{acl\_get\_tag\_type}, \funcd{acl\_get\_qualifier},
+\funcd{acl\_get\_permset} si potranno leggere rispettivamente tipo,
+qualificatore e permessi mentre con le corrispondente funzioni
+\funcd{acl\_set\_tag\_type}, \funcd{acl\_set\_qualifier},
+\funcd{acl\_set\_permset} si possono impostare i valori; in entrambi i casi
+vengono utilizzati tipi di dato ad hoc.\footnote{descritti nelle singole
+ pagine di manuale.} Si possono poi copiare i valori di una voce da una ACL
+ad un altra con \funcd{acl\_copy\_entry} o eliminare una voce da una ACL con
+\funcd{acl\_delete\_entry}.
-Per questo motivo erano state progressivamente introdotte nelle varie versioni
-di Unix dei meccanismi di gestione dei permessi dei file più flessibili, nella
-forma delle cosiddette \textit{Access Control List} (indicate usualmente con
-la sigla ACL). Nello sforzo di standardizzare queste funzionalità era stato
-creato un gruppo di lavoro il cui scopo era estendere lo standard POSIX 1003
-attraverso due nuovi insiemi di specifiche, la POSIX 1003.1e per l'interfaccia
-di programmazione e la POSIX 1003.2c per i comandi di shell.
+\itindend{Access~Control~List}
-Gli obiettivi erano però forse troppo ambizioni, e nel gennaio del 1998 i
-finanziamenti vennero ritirati senza che si fosse arrivati alla definizione di
-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 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
-\itindex{Extended~Attributes} \textit{Extended Attributes} (appena trattati in
-sez.~\ref{sec:file_xattr}), e fornire tutte le relative funzioni di gestione
-tramite una libreria, \texttt{libacl} che nasconde i dettagli implementativi
-delle ACL e presenta ai programmi una interfaccia che fa riferimento allo
-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 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}
+\subsection{La gestione delle \textit{capabilities}}
+\label{sec:proc_capabilities}
-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.
+\itindbeg{capabilities}
-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.
+Come accennato in sez.~\ref{sec:proc_access_id} l'architettura classica della
+gestione dei privilegi in un sistema unix-like ha il sostanziale problema di
+fornire all'amministratore dei poteri troppo ampi, questo comporta che anche
+quando si siano predisposte delle misure di protezione per in essere in grado
+di difendersi dagli effetti di una eventuale compromissione del
+sistema,\footnote{come montare un filesystem in sola lettura per impedirne
+ modifiche, o marcare un file come immutabile.} una volta che questa sia
+stata effettuata e si siano ottenuti i privilegi di amministratore, queste
+potranno essere comunque rimosse.\footnote{nei casi elencati nella precedente
+ nota si potrà sempre rimontare il sistema in lettura-scrittura, o togliere
+ la marcatura di immutabilità.}
-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.
+Il problema consiste nel fatto che nell'architettura tradizionale di un
+sistema unix-like i controlli di accesso sono basati su un solo livello di
+separazione: per i processi normali essi sono posti in atto, mentre per i
+processi con i privilegi di amministratore essi non vengono neppure eseguiti;
+per questo motivo non era previsto alcun modo per evitare che un processo con
+diritti di amministratore non potesse eseguire certe operazioni, o per cedere
+definitivamente alcuni privilegi da un certo momento in poi.
-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}.}
+Per ovviare a tutto ciò, a partire dai kernel della serie 2.2, è stato
+introdotto un meccanismo, detto \textit{capabilities}, che consentisse di
+suddividere i vari privilegi tradizionalmente associati all'amministratore in
+un insieme di \textsl{capacità} distinte. L'idea era che queste capacità
+potessero essere abilitate e disabilitate in maniera indipendente per ciascun
+processo con privilegi di amministratore, permettendo così una granularità
+molto più fine nella distribuzione degli stessi che evitasse la originaria
+situazione di ``\textsl{tutto o nulla}''.
-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}.
+Il meccanismo completo delle \textit{capabilities}\footnote{l'implementazione
+ si rifà ad una bozza di quello che doveva diventare lo standard POSIX.1e,
+ poi abbandonato.} prevede inoltre la possibilità di associare le stesse ai
+singoli file eseguibili, in modo da poter stabilire quali capacità possono
+essere utilizzate quando viene messo in esecuzione uno specifico programma; ma
+il supporto per questa funzionalità è stato introdotto soltanto a partire dal
+kernel 2.6.24; fino ad allora doveva essere il programma stesso ad eseguire
+una riduzione esplicita delle sue capacità, cosa che ha reso l'uso di questa
+funzionalità poco diffuso, vista la presenza di meccanismi alternativi come
+\index{SELinux} SELinux.
-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.
+Per gestire questo meccanismo ciascun processo porta con sé tre distinti
+insiemi di \textit{capabilities}, che vengono denominati rispettivamente
+\textit{effective}, \textit{permitted} ed \textit{inherited}. Questi insiemi
+vengono mantenuti in forma di tre diverse maschere binarie,\footnote{il kernel
+ li mantiene, come i vari identificatori di sez.~\ref{sec:proc_setuid},
+ all'interno della \struct{task\_struct} di ciascun processo (vedi
+ fig.~\ref{fig:proc_task_struct}), nei tre campi \texttt{cap\_effective},
+ \texttt{cap\_inheritable}, \texttt{cap\_permitted} del tipo
+ \texttt{kernel\_cap\_t}; questo è attualmente definito come intero a 32 bit,
+ il che comporta un massimo di 32 \textit{capabilities} distinte.} in cui
+ciascun bit corrisponde ad una capacità diversa.
-Dato che questa è la ragione che ha portato alla loro creazione, la principale
-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*}
+L'utilizzo di tre distinti insiemi serve a fornire una interfaccia flessibile
+per l'uso delle \textit{capabilities}, con scopi analoghi a quelli per cui
+sono mantenuti i diversi insiemi di identificatori di
+sez.~\ref{sec:proc_setuid}; il loro significato è il seguente:
+\begin{basedescript}{\desclabelwidth{2.0cm}\desclabelstyle{\nextlinelabel}}
+\item[\textit{effective}] l'insieme delle \textit{capabilities}
+ ``\textsl{effettive}'', cioè di quelle che vengono effettivamente usate dal
+ kernel quando deve eseguire il controllo di accesso per le varie operazioni
+ compiute dal processo.
+\item[\textit{permitted}] l'insieme delle \textit{capabilities}
+ ``\textsl{permesse}'', cioè l'insieme di quelle capacità che un processo
+ \textsl{può} impostare come \textsl{effettive}. Se un processo cancella una
+ capacità da questo insieme non potrà più riassumerla (almeno che non esegua
+ un programma che è \acr{suid} di root).
+\item[\textit{inherited}] l'insieme delle \textit{capabilities}
+ ``\textsl{ereditabili}'', cioè quelle che vengono trasmesse ad un nuovo
+ programma eseguito attraverso una chiamata ad \func{exec} (con l'eccezione
+ del caso che questo sia \acr{suid} di root).
+\label{sec:capabilities_set}
+\end{basedescript}
-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}).
+Oltre a questi tre insiemi, che sono relativi al singolo processo, il kernel
+mantiene un insieme generale valido per tutto il sistema, chiamato
+\itindex{capabilities~bounding~set} \textit{capabilities bounding set}. Ogni
+volta che un programma viene posto in esecuzione con \func{exec} il contenuto
+degli insiemi \textit{effective} e \textit{permitted} vengono mascherati con
+un \textsl{AND} binario del contenuto corrente del \textit{capabilities
+ bounding set}, così che il nuovo processo potrà disporre soltanto delle
+capacità in esso elencate.
-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)}
+Il \textit{capabilities bounding set} è un parametro di sistema, accessibile
+attraverso il contenuto del file \procfile{/proc/sys/kernel/cap-bound}, che per
+questa sua caratteristica consente di impostare un limite generale alle
+capacità che possono essere accordate ai vari processi. Questo valore può
+essere impostato ad un valore arbitrario esclusivamente dal primo processo
+eseguito nel sistema (di norma cioè da \texttt{/sbin/init}), ogni processo
+eseguito successivamente (cioè con \textsl{pid} diverso da 1) anche se
+eseguito con privilegi di amministratore potrà soltanto rimuovere uno dei bit
+già presenti dell'insieme: questo significa che una volta rimossa una
+\textit{capability} dal \textit{capabilities bounding set} essa non sarà più
+disponibile, neanche per l'amministratore, a meno di un riavvio.
- 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}
+Quando un programma viene messo in esecuzione\footnote{cioè quando viene
+ eseguita la \func{execve} con cui lo si lancia; in corrispondenza di una
+ \func{fork} le \textit{capabilities} non vengono modificate.} esso eredita
+(nel senso che assume negli insiemi \textit{effective} e \textit{permitted})
+le \textit{capabilities} mantenute nell'insieme \textit{inherited}, a meno che
+non sia eseguito un programma \acr{suid} di root o la \func{exec} sia stata
+eseguita da un programma con \textsl{uid} reale zero; in tal caso il programma
+ottiene tutte le \textit{capabilities} presenti nel \textit{capabilities
+ bounding set}. In questo modo si può far si che ad un processo eseguito in
+un secondo tempo possano essere trasmesse solo un insieme limitato di
+capacità, impedendogli di recuperare quelle assenti nell'insieme
+\textit{inherited}. Si tenga presente invece che attraverso una \func{fork}
+vengono mantenute le stesse capacità del processo padre.
-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 \param{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 prototipo è:
-\begin{functions}
- \headdecl{sys/types.h}
- \headdecl{sys/acl.h}
-
- \funcdecl{int acl\_free(void * obj\_p)}
+% TODO verificare per process capability bounding set, vedi:
+% http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=3b7391de67da515c91f48aa371de77cb6cc5c07e
- 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}
+% TODO capire cosa cambia con i patch vari, vedi
+% http://lwn.net/Articles/280279/
+% http://lwn.net/Articles/256519/
+% http://lwn.net/Articles/211883/
-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)}
+Un elenco delle delle \textit{capabilities} disponibili su Linux, con una
+breve descrizione ed il nome delle costanti che le identificano, è riportato
+in tab.~\ref{tab:proc_capabilities};\footnote{l'elenco presentato questa
+ tabella, ripreso dalla pagina di manuale (accessibile con \texttt{man
+ capabilities}) e dalle definizioni in \texttt{linux/capabilities.h}, è
+ aggiornato al kernel 2.6.26.} la tabella è divisa in due parti, la prima
+riporta le \textit{capabilities} previste anche nella bozza dello standard
+POSIX1.e, la seconda quelle specifiche di Linux. Come si può notare dalla
+tabella alcune \textit{capabilities} attengono a singole funzionalità e sono
+molto specializzate, mentre altre hanno un campo di applicazione molto vasto,
+che è opportuno dettagliare maggiormente.
- 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}
+\begin{table}[!h!bt]
+ \centering
+ \footnotesize
+ \begin{tabular}{|l|p{12cm}|}
+ \hline
+ \textbf{Capacità}&\textbf{Descrizione}\\
+ \hline
+ \hline
+%
+% POSIX-draft defined capabilities.
+%
+ \const{CAP\_AUDIT\_WRITE}&La capacità di scrivere dati nel giornale di
+ auditing del kernel (dal kernel 2.6.11).\\
+ \const{CAP\_AUDIT\_CONTROL}& La capacità di abilitare e disabilitare il
+ controllo dell'auditing (dal kernel 2.6.11).\\
+ % TODO verificare questa roba dell'auditing
+ \const{CAP\_CHOWN} & La capacità di cambiare proprietario e gruppo
+ proprietario di un file (vedi
+ sez.~\ref{sec:file_ownership_management}).\\
+ \const{CAP\_DAC\_OVERRIDE}& La capacità di evitare il controllo dei
+ permessi di lettura, scrittura ed esecuzione dei
+ file,\footnotemark (vedi
+ sez.~\ref{sec:file_access_control}).\\
+ \const{CAP\_DAC\_READ\_SEARCH}& La capacità di evitare il controllo dei
+ permessi di lettura ed esecuzione per
+ le directory (vedi
+ sez.~\ref{sec:file_access_control}).\\
+ \const{CAP\_FOWNER} & La capacità di evitare il controllo della
+ proprietà di un file per tutte
+ le operazioni privilegiate non coperte dalle
+ precedenti \const{CAP\_DAC\_OVERRIDE} e
+ \const{CAP\_DAC\_READ\_SEARCH}.\\
+ \const{CAP\_FSETID} & La capacità di evitare la cancellazione
+ automatica dei bit \itindex{suid~bit} \acr{suid}
+ e \itindex{sgid~bit} \acr{sgid} quando un file
+ per i quali sono impostati viene modificato da
+ un processo senza questa capacità e la capacità
+ di impostare il bit \acr{sgid} su un file anche
+ quando questo è relativo ad un gruppo cui non si
+ appartiene (vedi
+ sez.~\ref{sec:file_perm_management}).\\
+ \const{CAP\_SETFCAP} & La capacità di impostare le
+ \textit{capabilities} di un file (dal kernel
+ 2.6.24).\\
+ \const{CAP\_KILL} & La capacità di mandare segnali a qualunque
+ processo (vedi sez.~\ref{sec:sig_kill_raise}).\\
+ \const{CAP\_SETGID} & La capacità di manipolare i group ID dei
+ processi, sia il principale che i supplementari,
+ (vedi sez.~\ref{sec:proc_setgroups}) che quelli
+ trasmessi tramite i socket \textit{unix domain}
+ (vedi sez.~\ref{sec:unix_socket}).\\
+ \const{CAP\_SETUID} & La capacità di manipolare gli user ID del
+ processo (vedi sez.~\ref{sec:proc_setuid}) e di
+ trasmettere un user ID arbitrario nel passaggio
+ delle credenziali coi socket \textit{unix
+ domain} (vedi sez.~\ref{sec:unix_socket}).\\
+%
+% Linux specific capabilities
+%
+\hline
+ \const{CAP\_IPC\_LOCK} & La capacità di effettuare il \textit{memory
+ locking} \itindex{memory~locking} con le
+ funzioni \func{mlock}, \func{mlockall},
+ \func{shmctl}, \func{mmap} (vedi
+ sez.~\ref{sec:proc_mem_lock} e
+ sez.~\ref{sec:file_memory_map}). \\
+ \const{CAP\_IPC\_OWNER} & La capacità di evitare il controllo dei permessi
+ per le operazioni sugli oggetti di
+ intercomunicazione fra processi (vedi
+ sez.~\ref{sec:ipc_sysv}).\\
+ \const{CAP\_LEASE} & La capacità di creare dei \textit{file lease}
+ \index{file!lease} (vedi
+ sez.~\ref{sec:file_asyncronous_lease})
+ pur non essendo proprietari del file (dal kernel
+ 2.4).\\
+ \const{CAP\_LINUX\_IMMUTABLE}& La capacità di impostare sui file gli
+ attributi \textit{immutable} e
+ \itindex{append~mode} \textit{append only} (se
+ supportati).\\
+ \const{CAP\_MKNOD} & La capacità di creare
+ \index{file!di~dispositivo} file di dispositivo
+ con \func{mknod} (vedi
+ sez.~\ref{sec:file_mknod}) (dal kernel 2.4).\\
+ \const{CAP\_NET\_ADMIN} & La capacità di eseguire alcune operazioni
+ privilegiate sulla rete.\\
+ \const{CAP\_NET\_BIND\_SERVICE}& La capacità di porsi in ascolto
+ su porte riservate (vedi
+ sez.~\ref{sec:TCP_func_bind}).\\
+ \const{CAP\_NET\_BROADCAST}& La capacità di consentire l'uso di socket in
+ \itindex{broadcast} \textit{broadcast} e
+ \itindex{multicast} \textit{multicast}.\\
+ \const{CAP\_NET\_RAW} & La capacità di usare socket \texttt{RAW} e
+ \texttt{PACKET} (vedi sez.~\ref{sec:sock_type}).\\
+ \const{CAP\_SETPCAP} & La capacità di impostare o rimuovere una
+ capacità.\\
+ % TODO cambiata nel 2.4.24 rc1 ?
+ \const{CAP\_SYS\_ADMIN} & La capacità di eseguire una serie di compiti
+ amministrativi. \\
+ \const{CAP\_SYS\_BOOT} & La capacità di fare eseguire un riavvio del
+ sistema.\\
+% TODO trattare reboot e kexec
+ \const{CAP\_SYS\_CHROOT}& La capacità di eseguire la funzione
+ \func{chroot} (vedi
+ sez.~\ref{sec:file_chroot}).\\
+ \const{CAP\_MAC\_ADMIN} & La capacità amministrare il MAC di Smack (dal
+ kernel 2.6.25).\\
+ \const{CAP\_MAC\_OVERRIDE}& La capacità evitare il MAC di Smack (dal
+ kernel 2.6.25).\\
+ \const{CAP\_SYS\_MODULE}& La capacità di caricare e rimuovere moduli del
+ kernel. \\
+ \const{CAP\_SYS\_NICE} & La capacità di modificare le priorità dei
+ processi. \\
+ \const{CAP\_SYS\_PACCT} & La capacità di usare le funzioni di
+ \textit{accounting} dei processi (vedi
+ sez.~\ref{sec:sys_bsd_accounting}).\\
+ \const{CAP\_SYS\_PTRACE}& La capacità di tracciare qualunque processo con
+ \func{ptrace} (vedi
+ sez.~\ref{sec:xxx_ptrace}).\\
+ \const{CAP\_SYS\_RAWIO} & La capacità di eseguire operazioni sulle porte
+ di I/O con \func{ioperm} e \func{iopl} (vedi
+ sez.~\ref{sec:file_io_port}).\\
+ \const{CAP\_SYS\_RESOURCE}& La capacità di superare le limitazioni sulle
+ risorse.\\
+ \const{CAP\_SYS\_TIME} & La capacità di modificare il tempo di sistema
+ (vedi sez.~\ref{sec:sys_time}).\\
+ \const{CAP\_SYS\_TTY\_CONFIG}& La capacità di simulare un \textit{hangup}
+ della console, con la funzione
+ \func{vhangup}.\\
+ \hline
+ \end{tabular}
+ \caption{Le costanti che identificano le \textit{capabilities} presenti nel
+ kernel.}
+\label{tab:proc_capabilities}
+\end{table}
+
+\footnotetext{vale a dire i permessi caratteristici del modello classico del
+ controllo di accesso chiamato \itindex{Discrectionary~Access~Control~(DAC)}
+ \textit{Discrectionary Access Control} (da cui il nome DAC).}
+
+% TODO aggiungere CAP_SYSLOG, citata in http://lwn.net/Articles/429595/
+
+La prima di queste capacità ``\textsl{ampie}'' è \const{CAP\_FOWNER}, che
+rimuove le restrizioni poste ad un processo che non ha la proprietà di un file
+in un vasto campo di operazioni;\footnote{vale a dire la richiesta che
+ l'user-ID effettivo del processo (o meglio il \textit{filesystem user-ID},
+ vedi sez.~\ref{sec:proc_setuid}) coincida con quello del proprietario.}
+queste comprendono i cambiamenti dei permessi e dei tempi del file (vedi
+sez.~\ref{sec:file_perm_management} e sez.~\ref{sec:file_file_times}), le
+impostazioni degli attributi estesi e delle ACL (vedi
+sez.~\ref{sec:file_xattr} e \ref{sec:file_ACL}), poter ignorare lo
+\itindex{sticky~bit} \textit{sticky bit} nella cancellazione dei file (vedi
+sez.~\ref{sec:file_special_perm}), la possibilità di impostare il flag di
+\const{O\_NOATIME} con \func{open} e \func{fcntl} (vedi
+sez.~\ref{sec:file_open} e sez.~\ref{sec:file_fcntl}) senza restrizioni.
+
+Una seconda capacità che copre diverse operazioni, in questo caso riguardanti
+la rete, è \const{CAP\_NET\_ADMIN}, che consente di impostare le opzioni
+privilegiate dei socket (vedi sez.~\ref{sec:sock_generic_options}), abilitare
+il \itindex{multicast} \textit{multicasting}, eseguire la configurazione delle
+interfacce di rete (vedi sez.~\ref{sec:sock_ioctl_netdevice}) ed impostare la
+tabella di instradamento.
+
+Una terza \textit{capability} con vasto campo di applicazione è
+\const{CAP\_SYS\_ADMIN}, che copre una serie di operazioni amministrative,
+come impostare le quote disco (vedi sez.\ref{sec:disk_quota}), attivare e
+disattivare la swap, montare, rimontare e smontare filesystem (vedi
+sez.~\ref{sec:sys_file_config}), effettuare operazioni di controllo sugli
+oggetti dell'IPC di SysV (vedi sez.~\ref{sec:ipc_sysv}), operare sugli
+attributi estesi di classe \texttt{security} o \texttt{trusted} (vedi
+sez.~\ref{sec:file_xattr}), specificare un user-ID arbitrario nella
+trasmissione delle credenziali dei socket (vedi sez.~\ref{sec:socket_xxx}),
+assegnare classi privilegiate per lo scheduling dell'I/O (vedi
+sez.~\ref{sec:io_priority}), superare il limite di sistema sul numero massimo
+di file aperti,\footnote{quello indicato da \procfile{/proc/sys/fs/file-max}.}
+effettuare operazioni privilegiate sulle chiavi mantenute dal kernel (vedi
+sez.~\ref{sec:io_priority}), usare la funzione \func{lookup\_dcookie} (vedi
+sez.~\ref{sec:xxx_profiling}), usare \const{CLONE\_NEWNS} con \func{unshare},
+(vedi sez.~\ref{sec:process_clone}).
-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.
+Originariamente \const{CAP\_SYS\_NICE} riguardava soltanto la capacità di
+aumentare le priorità di esecuzione dei processi, come la diminuzione del
+valore di \textit{nice} (vedi sez.~\ref{sec:proc_sched_stand}), l'uso delle
+priorità \textit{real-time} (vedi sez.~\ref{sec:proc_real_time}), o
+l'impostazione delle affinità di processore (vedi
+sez.~\ref{sec:proc_sched_multiprocess}); ma con l'introduzione di priorità
+anche riguardo le operazioni di accesso al disco, e, nel caso di sistemi NUMA,
+alla memoria, essa viene a coprire anche la possibilità di assegnare priorità
+arbitrarie nell'accesso a disco (vedi sez.~\ref{sec:io_priority}) e nelle
+politiche di allocazione delle pagine di memoria ai nodi di un sistema NUMA.
-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)}
+Infine la \textit{capability} \const{CAP\_SYS\_RESOURCE} attiene alla
+possibilità di superare i limiti imposti sulle risorse di sistema, come usare
+lo spazio disco riservato all'amministratore sui filesystem che lo supportano,
+usare la funzione \func{ioctl} per controllare il \textit{journaling} sul
+filesystem \acr{ext3}, non subire le quote disco, aumentare i limiti sulle
+risorse (vedi sez.~\ref{sec:sys_resource_limit}) e sulle dimensioni dei
+messaggi delle code del SysV IPC (vedi sez.~\ref{sec:ipc_sysv_mq}).
- 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}
+Per la gestione delle \textit{capabilities} il kernel mette a disposizione due
+funzioni che permettono rispettivamente di leggere ed impostare i valori dei
+tre insiemi illustrati in precedenza. Queste due funzioni sono \funcd{capget}
+e \funcd{capset} e costituiscono l'interfaccia di gestione basso livello; i
+loro rispettivi prototipi sono:
+\begin{functions}
+ \headdecl{sys/capability.h}
-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.
+ \funcdecl{int capget(cap\_user\_header\_t hdrp, cap\_user\_data\_t datap)}
+ Legge le \textit{capabilities}.
-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)}
+ \funcdecl{int capset(cap\_user\_header\_t hdrp, const cap\_user\_data\_t
+ datap)}
+ Imposta le \textit{capabilities}.
- 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.
+ \bodydesc{Entrambe le funzioni ritornano 0 in caso di successo e -1 in caso
+ di errore, nel qual caso \var{errno} può assumere i valori:
+ \begin{errlist}
+ \item[\errcode{ESRCH}] si è fatto riferimento ad un processo inesistente.
+ \item[\errcode{EPERM}] si è tentato di aggiungere una capacità
+ nell'insieme delle \textit{capabilities} permesse, o di impostare una
+ capacità non presente nell'insieme di quelle permesse negli insieme
+ delle effettive o ereditate, o si è cercato di impostare una
+ \textit{capability} di un altro processo senza avare
+ \const{CAP\_SETPCAP}.
\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}.
-
+ ed inoltre \errval{EFAULT} ed \errval{EINVAL}.
}
+
\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}.
+Queste due funzioni prendono come argomenti due tipi di dati dedicati,
+definiti come puntatori a due strutture specifiche di Linux, illustrate in
+fig.~\ref{fig:cap_kernel_struct}. Per poterle utilizzare occorre anche
+cancellare la macro \macro{\_POSIX\_SOURCE}.\footnote{per farlo occorre
+ utilizzare la direttiva di preprocessore \direct{undef}; si dovrà cioè
+ inserire una istruzione \texttt{\#undef \_POSIX\_SOURCE} prima di includere
+ \texttt{sys/capability.h}.} Si tenga presente che le strutture di
+fig.~\ref{fig:cap_kernel_struct}, come i prototipi delle due funzioni
+\func{capget} e \func{capset}, sono soggette ad essere modificate con il
+cambiamento del kernel (in particolare i tipi di dati delle strutture) ed
+anche se finora l'interfaccia è risultata stabile, non c'è nessuna
+assicurazione che questa venga mantenuta.\footnote{anzi, visto lo scarso
+ utilizzo di questa funzionalità ci sono state varie discussioni fra gli
+ sviluppatori del kernel relative all'eliminarla o al modificarla
+ radicalmente.} Pertanto se si vogliono scrivere programmi portabili che
+possano essere eseguiti su qualunque versione del kernel è opportuno
+utilizzare le interfacce di alto livello.
-\begin{table}[htb]
- \centering
+\begin{figure}[!htb]
\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}
+ \centering
+ \begin{minipage}[c]{15cm}
+ \includestruct{listati/cap_user_header_t.h}
+ \end{minipage}
+ \normalsize
+ \caption{Definizione delle strutture a cui fanno riferimento i puntatori
+ \structd{cap\_user\_header\_t} e \structd{cap\_user\_data\_t} usati per
+ l'interfaccia di gestione di basso livello delle \textit{capabilities}.}
+ \label{fig:cap_kernel_struct}
+\end{figure}
-Si tenga presente che nel caso di \func{acl\_get\_file} occorrerà che il
-processo chiamante abbia privilegi di accesso sufficienti 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.
+La struttura a cui deve puntare l'argomento \param{hdrp} serve ad indicare,
+tramite il campo \var{pid}, il processo del quale si vogliono leggere o
+modificare le \textit{capabilities}. Il campo \var{version} deve essere
+impostato al valore della versione delle usata dal kernel (quello indicato
+dalla costante \const{\_LINUX\_CAPABILITY\_VERSION} di
+fig.~\ref{fig:cap_kernel_struct}) altrimenti le funzioni ritorneranno con un
+errore di \errcode{EINVAL}, restituendo nel campo stesso il valore corretto
+della versione in uso. La struttura a cui deve puntare l'argomento
+\param{datap} invece conterrà i valori letti o da impostare per i tre insiemi
+delle capacità del processo.
-Infine si potrà creare una ACL direttamente dalla sua rappresentazione
-testuale con la funzione \funcd{acl\_from\_text}, il cui prototipo è:
+Dato che le precedenti funzioni, oltre ad essere specifiche di Linux, non
+garantiscono la stabilità nell'interfaccia, è sempre opportuno effettuare la
+gestione delle \textit{capabilities} utilizzando le funzioni di libreria a
+questo dedicate. Queste funzioni, che seguono quanto previsto nelle bozze
+dello standard POSIX.1e, non fanno parte delle \acr{glibc} e sono fornite in
+una libreria a parte,\footnote{la libreria è \texttt{libcap2}, nel caso di
+ Debian può essere installata con il pacchetto omonimo.} pertanto se un
+programma le utilizza si dovrà indicare esplicitamente l'uso della suddetta
+libreria attraverso l'opzione \texttt{-lcap} del compilatore.
+
+Le funzioni dell'interfaccia delle bozze di POSIX.1e prevedono l'uso di uno
+tipo di dato opaco, \type{cap\_t}, come puntatore ai dati mantenuti nel
+cosiddetto \textit{capability state},\footnote{si tratta in sostanza di un
+ puntatore ad una struttura interna utilizzata dalle librerie, i cui campi
+ non devono mai essere acceduti direttamente.} in sono memorizzati tutti i
+dati delle \textit{capabilities}. In questo modo è possibile mascherare i
+dettagli della gestione di basso livello, che potranno essere modificati senza
+dover cambiare le funzioni dell'interfaccia, che faranno riferimento soltanto
+ad oggetti di questo tipo. L'interfaccia pertanto non soltanto fornisce le
+funzioni per modificare e leggere le \textit{capabilities}, ma anche quelle
+per gestire i dati attraverso \type{cap\_t}.
+
+La prima funzione dell'interfaccia è quella che permette di inizializzare un
+\textit{capability state}, allocando al contempo la memoria necessaria per i
+relativi dati. La funzione è \funcd{cap\_init} ed il suo prototipo è:
\begin{functions}
- \headdecl{sys/types.h}
- \headdecl{sys/acl.h}
-
- \funcdecl{acl\_t acl\_from\_text(const char *buf\_p)}
+ \headdecl{sys/capability.h}
- Crea una ACL a partire dalla sua rappresentazione testuale.
+ \funcdecl{cap\_t cap\_init(void)}
+ Crea ed inizializza un \textit{capability state}.
- \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}
-
-}
+ \bodydesc{La funzione ritorna un valore non nullo in caso di successo e
+ \macro{NULL} in caso di errore, nel qual caso \var{errno} assumerà il
+ valore \errval{ENOMEM}.
+ }
\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} e
-\texttt{group} e indica l'utente o il gruppo a cui la voce si riferisce; i
-permessi sono espressi con una tripletta di lettere analoga a quella usata per
-i permessi dei file.\footnote{vale a dire \texttt{r} per il permesso di
- lettura, \texttt{w} per il permesso di scrittura, \texttt{x} per il permesso
- di esecuzione (scritti in quest'ordine) e \texttt{-} per l'assenza del
- permesso.}
+La funzione restituisce il puntatore \type{cap\_t} ad uno stato inizializzato
+con tutte le \textit{capabilities} azzerate. In caso di errore (cioè quando
+non c'è memoria sufficiente ad allocare i dati) viene restituito \macro{NULL}
+ed \var{errno} viene impostata a \errval{ENOMEM}. La memoria necessaria a
+mantenere i dati viene automaticamente allocata da \func{cap\_init}, ma dovrà
+essere disallocata esplicitamente quando non è più necessaria utilizzando, per
+questo l'interfaccia fornisce una apposita funzione, \funcd{cap\_free}, il cui
+prototipo è:
+\begin{functions}
+ \headdecl{sys/capability.h}
-Va precisato che i due tipi \texttt{user} e \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, ed in genere si scrivono per prima delle altre.
-Il significato delle voci di tipo \texttt{mask} e \texttt{mark} è evidente. In
-questa forma si possono anche inserire dei commenti precedendoli con il
-carattere ``\texttt{\#}''.
+ \funcdecl{int cap\_free(void *obj\_d)}
+ Disalloca la memoria allocata per i dati delle \textit{capabilities}.
+
+ \bodydesc{La funzione ritorna 0 in caso di successo e $-1$ in caso di
+ errore, nel qual caso \var{errno} assumerà il valore \errval{EINVAL}.
+ }
+\end{functions}
-La forma breve prevede invece la scrittura delle singole voci su una riga,
-separate da virgole; come specificatori del tipo di voce si possono usare le
-iniziali dei valori usati nella forma estesa (cioè ``\texttt{u}'',
-``\texttt{g}'', ``\texttt{o}'' e ``\texttt{m}''), mentre le altri parte della
-voce sono le stesse. In questo caso non sono consentiti permessi.
+La funzione permette di liberare la memoria allocata dalle altre funzioni
+della libreria sia per un \textit{capability state}, nel qual caso l'argomento
+dovrà essere un dato di tipo \type{cap\_t}, che per una descrizione testuale
+dello stesso,\footnote{cioè quanto ottenuto tramite la funzione
+ \func{cap\_to\_text}.} nel qual caso l'argomento dovrà essere un dato di
+tipo \texttt{char *}. Per questo l'argomento \param{obj\_d} è dichiarato come
+\texttt{void *} e deve sempre corrispondere ad un puntatore ottenuto tramite
+le altre funzioni della libreria, altrimenti la funzione fallirà con un errore
+di \errval{EINVAL}.
-Per la conversione inversa, che consente di ottenere la rappresentazione
-testuale di una ACL, sono invece disponibili due funzioni, la prima delle due,
-di uso più immediato, è \funcd{acl\_to\_text}, il cui prototipo è:
+Infine si può creare una copia di un \textit{capability state} ottenuto in
+precedenza tramite la funzione \funcd{cap\_dup}, il cui prototipo è:
\begin{functions}
- \headdecl{sys/types.h}
- \headdecl{sys/acl.h}
-
- \funcdecl{char * acl\_to\_text(acl\_t acl, ssize\_t *len\_p)}
+ \headdecl{sys/capability.h}
- Produce la rappresentazione testuale di una ACL.
+ \funcdecl{cap\_t cap\_dup(cap\_t cap\_p)}
+ Duplica un \textit{capability state} restituendone una copia.
- \bodydesc{La funzione restituisce il puntatore ad una stringa con la
- rappresentazione testuale della ACL 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 ACL indicata da \param{acl} non è valida.
- \end{errlist}
-
-}
+ \bodydesc{La funzione ritorna un valore non nullo in caso di successo e
+ \macro{NULL} in caso di errore, nel qual caso \var{errno} potrà assumere i
+ valori \errval{ENOMEM} o \errval{EINVAL}.
+ }
\end{functions}
-La funzione restituisce il puntatore ad una stringa terminata da NUL
-contenente la rappresentazione in forma estesa della ACL passata come
-argomento, ed alloca automaticamente la memoria necessaria. Questa dovrà poi
-essere liberata, quando non più necessaria, con \func{acl\_free}. Se
-nell'argomento \param{len\_p} si passa un valore puntatore ad una variabile
-intera in questa verrà restituita la dimensione della stringa con la
-rappresentazione testuale (non comprendente il carattere nullo finale).
+La funzione crea una copia del \textit{capability state} posto all'indirizzo
+\param{cap\_p} che si è passato come argomento, restituendo il puntatore alla
+copia, che conterrà gli stessi valori delle \textit{capabilities} presenti
+nell'originale. La memoria necessaria viene allocata automaticamente dalla
+funzione. Una volta effettuata la copia i due \textit{capability state}
+potranno essere modificati in maniera completamente
+indipendente.\footnote{alla fine delle operazioni si ricordi però di
+ disallocare anche la copia, oltre all'originale. }
-La seconda funzione, \funcd{acl\_to\_any\_text}, permette di controllare con
-dovizia di dettagli la generazione della stringa contenente la
-rappresentazione testuale della ACL, il suo prototipo è:
+Una seconda classe di funzioni di servizio previste dall'interfaccia sono
+quelle per la gestione dei dati contenuti all'interno di un \textit{capability
+ state}; la prima di queste è \funcd{cap\_clear}, il cui prototipo è:
\begin{functions}
- \headdecl{sys/types.h}
- \headdecl{sys/acl.h}
+ \headdecl{sys/capability.h}
+
+ \funcdecl{int cap\_clear(cap\_t cap\_p)}
+ Inizializza un \textit{capability state} cancellando tutte le
+ \textit{capabilities}.
- \funcdecl{char * acl\_to\_any\_text(acl\_t acl, const char *prefix, char
- separator, int options)}
+ \bodydesc{La funzione ritorna 0 in caso di successo e $-1$ in caso di
+ errore, nel qual caso \var{errno} assumerà il valore \errval{EINVAL}.
+ }
+\end{functions}
- Produce la rappresentazione testuale di una ACL.
+La funzione si limita ad azzerare tutte le \textit{capabilities} presenti nel
+\textit{capability state} all'indirizzo \param{cap\_p} passato come argomento,
+restituendo uno stato \textsl{vuoto}, analogo a quello che si ottiene nella
+creazione con \func{cap\_init}.
- \bodydesc{La funzione restituisce il puntatore ad una stringa con la
- rappresentazione testuale della ACL in caso di successo e \code{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 ACL indicata da \param{acl} non è valida.
- \end{errlist}
+Per la gestione dei valori delle \textit{capabilities} presenti in un
+\textit{capability state} l'interfaccia prevede due funzioni,
+\funcd{cap\_get\_flag} e \funcd{cap\_set\_flag}, che permettono
+rispettivamente di leggere o impostare il valore di un flag delle
+\textit{capabilities}; i rispettivi prototipi sono:
+\begin{functions}
+ \headdecl{sys/capability.h}
+ \funcdecl{int cap\_get\_flag(cap\_t cap\_p, cap\_value\_t cap, cap\_flag\_t
+ flag, cap\_flag\_value\_t *value\_p)}
+ Legge il valore di una \textit{capability}.
+
+ \funcdecl{int cap\_set\_flag(cap\_t cap\_p, cap\_flag\_t flag, int ncap,
+ cap\_value\_t *caps, cap\_flag\_value\_t value)}
+ Imposta il valore di una \textit{capability}.
+
+ \bodydesc{Le funzioni ritornano 0 in caso di successo e $-1$ in caso di
+ errore, nel qual caso \var{errno} assumerà il valore \errval{EINVAL}.
}
\end{functions}
-La funzione converte in formato testo la ACL indicata dall'argomento
-\param{acl}, usando il carattere \param{separator} come separatore delle
-singole voci; se l'argomento \param{prefix} non è nullo la stringa da esso
-indicata viene utilizzata come prefisso per le singole voci.
-
-L'ultimo argomento, \param{options}, consente di controllare la modalità con
-cui viene generata la rappresentazione testuale. Un valore nullo fa si che
-vengano usati gli identificatori standard \texttt{user}, \texttt{group},
-\texttt{other} e \texttt{mask} con i nomi di utenti e gruppi risolti rispetto
-ai loro valori numerici. Altrimenti si può specificare un valore in forma di
-maschera binaria, da ottenere con un OR aritmetico dei valori riportati in
-tab.~\ref{tab:acl_to_text_options}.
+In entrambe le funzioni l'argomento \param{cap\_p} indica il puntatore al
+\textit{capability state} su cui operare, mentre l'argomento \param{flag}
+indica su quale dei tre insiemi illustrati a
+pag.~\pageref{sec:capabilities_set} si intende operare. Questi devono essere
+specificati con una variabile di tipo \type{cap\_flag\_t} che può assumere
+esclusivamente\footnote{si tratta in effetti di un tipo enumerato, come si può
+ verificare dalla sua definizione che si trova in
+ \texttt{/usr/include/sys/capability.h}.} uno dei valori illustrati in
+tab.~\ref{tab:cap_set_identifier}.
\begin{table}[htb]
\centering
\footnotesize
- \begin{tabular}{|l|p{8cm}|}
+ \begin{tabular}[c]{|l|l|}
\hline
- \textbf{Tipo} & \textbf{Descrizione} \\
+ \textbf{Valore} & \textbf{Significato} \\
\hline
\hline
- \const{TEXT\_ABBREVIATE} & stampa le voci in forma abbreviata.\\
- \const{TEXT\_NUMERIC\_IDS} & non effettua la risoluzione numerica di
- user-ID e group-ID.\\
- \const{TEXT\_SOME\_EFFECTIVE}& per ciascuna voce che contiene permessi che
- vengono eliminati dalla \const{ACL\_MASK}
- viene generato un commento con i permessi
- effettivamente risultanti; il commento è
- separato con un tabulatore.\\
- \const{TEXT\_ALL\_EFFECTIVE} & viene generato un commento con i permessi
- effettivi per ciascuna voce che contiene
- permessi citati nella \const{ACL\_MASK},
- anche quando questi non vengono modificati
- da essa; il commento è separato con un
- tabulatore.\\
- \const{TEXT\_SMART\_INDENT} & da usare in combinazione con le precedenti
- \const{TEXT\_SOME\_EFFECTIVE} e
- \const{TEXT\_ALL\_EFFECTIVE} aumenta
- automaticamente il numero di spaziatori
- prima degli eventuali commenti in modo da
- mantenerli allineati.\\
+ \const{CAP\_EFFECTIVE} & Capacità dell'insieme \textsl{effettivo}.\\
+ \const{CAP\_PERMITTED} & Capacità dell'insieme \textsl{permesso}.\\
+ \const{CAP\_INHERITABLE}& Capacità dell'insieme \textsl{ereditabile}.\\
\hline
\end{tabular}
- \caption{Possibili valori per l'argomento \param{options} di
- \func{acl\_to\_any\_text}.}
- \label{tab:acl_to_text_options}
+ \caption{Valori possibili per il tipo di dato \type{cap\_flag\_t} che
+ identifica gli insiemi delle \textit{capabilities}.}
+ \label{tab:cap_set_identifier}
\end{table}
-Come per \func{acl\_to\_text} anche in questo caso il buffer contenente la
-rappresentazione testuale dell'ACL, di cui la funzione restituisce
-l'indirizzo, viene allocato automaticamente, e dovrà essere esplicitamente
-disallocato con una chiamata ad \func{acl\_free}. Si tenga presente infine che
-questa funzione è una estensione specifica di Linux, e non è presente nella
-bozza dello standard POSIX.1e.
-
-Per quanto utile per la visualizzazione o l'impostazione da comando delle ACL,
-la forma testuale non è la più efficiente per poter memorizzare i dati
-relativi ad una ACL, ad esempio quando si vuole eseguirne una copia a scopo di
-archiviazione. Per questo è stata prevista la possibilità di utilizzare una
-rappresentazione delle ACL in una apposita forma binaria contigua e
-persistente. È così possibile copiare il valore di una ACL in un buffer e da
-questa rappresentazione tornare indietro e generare una ACL.
-
-Lo standard POSIX.1e prevede a tale scopo tre funzioni, la prima e più
-semplice è \funcd{acl\_size}, che consente di ottenere la dimensione che avrà
-la citata rappresentazione binaria, in modo da poter allocare per essa un
-buffer di dimensione sufficiente, il suo prototipo è:
-\begin{functions}
- \headdecl{sys/types.h}
- \headdecl{sys/acl.h}
-
- \funcdecl{ssize\_t acl\_size(acl\_t acl)}
-
- Determina la dimensione della rappresentazione binaria di una ACL.
-
- \bodydesc{La funzione restituisce in caso di successo la dimensione in byte
- della rappresentazione binaria della ACL indicata da \param{acl} e $-1$ in
- caso di errore, nel qual caso \var{errno} assumerà uno dei valori:
- \begin{errlist}
- \item[\errcode{EINVAL}] la ACL indicata da \param{acl} non è valida.
- \end{errlist}
-
-}
-\end{functions}
-
-Prima di effettuare la lettura della rappresentazione binaria è sempre
-necessario allocare un buffer di dimensione sufficiente a contenerla, pertanto
-prima si dovrà far ricorso a \funcd{acl\_size} per ottenere tale dimensione e
-poi allocare il buffer con una delle funzioni di
-sez.~\ref{sec:proc_mem_alloc}. Una volta terminato l'uso della
-rappresentazione binaria, il buffer dovrà essere esplicitamente disallocato.
-
-La funzione che consente di leggere la rappresentazione binaria di una ACL è
-\funcd{acl\_copy\_ext}, il cui prototipo è:
-\begin{functions}
- \headdecl{sys/types.h}
- \headdecl{sys/acl.h}
-
- \funcdecl{ssize\_t acl\_copy\_ext(void *buf\_p, acl\_t acl, ssize\_t size)}
+La capacità che si intende controllare o impostare invece deve essere
+specificata attraverso una variabile di tipo \type{cap\_value\_t}, che può
+prendere come valore uno qualunque di quelli riportati in
+tab.~\ref{tab:proc_capabilities}, in questo caso però non è possibile
+combinare diversi valori in una maschera binaria, una variabile di tipo
+\type{cap\_value\_t} deve indicare una sola capacità.\footnote{nel file di
+ header citato nella nota precedente il tipo \type{cap\_value\_t} è definito
+ come \ctyp{int}, ma i valori validi sono soltanto quelli di
+ tab.~\ref{tab:proc_capabilities}.}
- Ottiene la rappresentazione binaria di una ACL.
+Infine lo stato di una capacità è descritto ad una variabile di tipo
+\type{cap\_flag\_value\_t}, che a sua volta può assumere soltanto
+uno\footnote{anche questo è un tipo enumerato.} dei valori di
+tab.~\ref{tab:cap_value_type}.
- \bodydesc{La funzione restituisce in caso di successo la dimensione in byte
- della rappresentazione binaria della ACL indicata da \param{acl} e $-1$ in
- caso di errore, nel qual caso \var{errno} assumerà uno dei valori:
- \begin{errlist}
- \item[\errcode{EINVAL}] la ACL indicata da \param{acl} non è valida o
- \param{size} è negativo o nullo.
- \item[\errcode{ERANGE}] il valore di \param{size} è più piccolo della
- dimensione della rappresentazione della ACL.
- \end{errlist}
+\begin{table}[htb]
+ \centering
+ \footnotesize
+ \begin{tabular}[c]{|l|l|}
+ \hline
+ \textbf{Valore} & \textbf{Significato} \\
+ \hline
+ \hline
+ \const{CAP\_CLEAR}& La capacità non è impostata.\\
+ \const{CAP\_SET} & La capacità è impostata.\\
+ \hline
+ \end{tabular}
+ \caption{Valori possibili per il tipo di dato \type{cap\_flag\_value\_t} che
+ indica lo stato di una capacità.}
+ \label{tab:cap_value_type}
+\end{table}
-}
-\end{functions}
+La funzione \func{cap\_get\_flag} legge lo stato della capacità indicata
+dall'argomento \param{cap} all'interno dell'insieme indicato dall'argomento
+\param{flag} e ne restituisce il valore nella variabile posta all'indirizzo
+puntato dall'argomento \param{value\_p}; è possibile cioè leggere soltanto uno
+stato di una capacità alla volta.
-La funzione salverà la rappresentazione binaria della ACL indicata da
-\param{acl} sul buffer posto all'indirizzo \param{buf\_p} e lungo \param{size}
-byte, restituendo la dimensione della stessa come valore di ritorno. Qualora
-la dimensione della rappresentazione ecceda il valore di \param{size} la
-funzione fallirà con un errore di \errcode{ERANGE}. La funzione non ha nessun
-effetto sulla ACL indicata da \param{acl}.
+La funzione \func{cap\_set\_flag} può invece impostare in una sola chiamata
+più \textit{capabilities}, anche se solo all'interno dello stesso insieme. Per
+questo motivo essa prende un vettore di valori di tipo \type{cap\_value\_t}
+nell'argomento \param{caps}, la cui dimensione viene specificata dall'argomento
+\param{ncap}. Il tipo di impostazione da eseguire (cancellazione o
+impostazione) viene indicato dall'argomento \param{value}.
-Viceversa se si vuole ripristinare una ACL a partire dalla rappresentazione
-binaria della stessa disponibile in un buffer si potrà usare la funzione
-\funcd{acl\_copy\_int}, il cui prototipo è:
+Per la visualizzazione dello stato delle \textit{capabilities} l'interfaccia
+prevede una funzione apposita, \funcd{cap\_to\_text}, il cui prototipo è:
\begin{functions}
- \headdecl{sys/types.h}
- \headdecl{sys/acl.h}
-
- \funcdecl{ssize\_t acl\_copy\_int(const void *buf\_p)}
-
- Ripristina la rappresentazione binaria di una ACL.
+ \headdecl{sys/capability.h}
- \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}] il buffer all'indirizzo \param{buf\_p} non contiene
- una rappresentazione corretta di una ACL.
- \item[\errcode{ENOMEM}] non c'è memoria sufficiente per allocare un oggetto
- \type{acl\_t} per la ACL richiesta.
- \end{errlist}
+ \funcdecl{char * cap\_to\_text(cap\_t caps, ssize\_t * length\_p)}
-}
+ Genera una visualizzazione testuale delle \textit{capabilities}.
+
+ \bodydesc{La funzione ritorna un puntatore alla stringa con la descrizione
+ delle \textit{capabilities} in caso di successo e \val{NULL} in caso di
+ errore, nel qual caso \var{errno} può assumere i valori \errval{EINVAL} o
+ \errval{ENOMEM}.
+ }
\end{functions}
-La funzione in caso di successo alloca autonomamente un oggetto di tipo
-\type{acl\_t} che viene restituito come valore di ritorno con il contenuto
-della ACL rappresentata dai dati contenuti nel buffer puntato da
-\param{buf\_p}. Si ricordi che come per le precedenti funzioni l'oggetto
-\type{acl\_t} dovrà essere disallocato esplicitamente al termine del suo
-utilizzo.
+La funzione ritorna l'indirizzo di una stringa contente la descrizione
+testuale del contenuto del \textit{capabilities state} \param{caps} passato
+come argomento, e, qualora l'argomento \param{length\_p} sia diverso da
+\val{NULL}, restituisce nella variabile intera da questo puntata la lunghezza
+della stringa. La stringa restituita viene allocata automaticamente dalla
+funzione e pertanto dovrà essere liberata con \func{cap\_free}.
-Una volta che si disponga della ACL desiderata, questa potrà essere impostata
-su un file o una directory. Per impostare una ACL sono disponibili due
-funzioni; la prima è \funcd{acl\_set\_file}, che opera sia su file che su
-directory, ed il cui prototipo è:
+Fin quei abbiamo trattato solo le funzioni di servizio relative alla
+manipolazione dei \textit{capabilities state}; l'interfaccia di gestione
+prevede però anche le funzioni per la gestione delle \textit{capabilities}
+stesse. La prima di queste è \funcd{cap\_get\_proc} che consente la lettura
+delle \textit{capabilities} del processo corrente, il suo prototipo è:
\begin{functions}
- \headdecl{sys/types.h}
- \headdecl{sys/acl.h}
-
- \funcdecl{int acl\_set\_file(const char *path, acl\_type\_t type, acl\_t
- acl)}
-
- Imposta una ACL su un file o una directory.
+ \headdecl{sys/capability.h}
- \bodydesc{La funzione restituisce $0$ in caso di successo e $-1$ in caso di
- errore, nel qual caso \var{errno} assumerà uno dei valori:
- \begin{errlist}
- \item[\errcode{EACCES}] o un generico errore di accesso a \param{path} o il
- valore di \param{type} specifica una ACL il cui tipo non può essere
- assegnato a \param{path}.
- \item[\errcode{EINVAL}] o \param{acl} non è una ACL valida, o \param{type}
- ha in valore non corretto.
- \item[\errcode{ENOSPC}] non c'è spazio disco sufficiente per contenere i
- dati aggiuntivi della ACL.
- \item[\errcode{ENOTSUP}] si è cercato di impostare una ACL su un file
- contenuto in un filesystem che non supporta le ACL.
- \end{errlist}
- ed inoltre \errval{ENOENT}, \errval{ENOTDIR}, \errval{ENAMETOOLONG},
- \errval{EROFS}, \errval{EPERM}.
-}
+ \funcdecl{cap\_t cap\_get\_proc(void)}
+ Legge le \textit{capabilities} del processo corrente.
+
+ \bodydesc{La funzione ritorna un valore diverso da \val{NULL} in caso di
+ successo e \val{NULL} in caso di errore, nel qual caso \var{errno} può
+ assumere i valori \errval{EINVAL}, \errval{EPERM} o \errval{ENOMEM}. }
\end{functions}
-La funzione consente di assegnare la ACL contenuta in \param{acl} al file o
-alla directory indicate dal pathname \param{path}, mentre con \param{type} si
-indica il tipo di ACL utilizzando le costanti di tab.~\ref{tab:acl_type}, ma
-si tenga presente che le ACL di default possono essere solo impostate
-qualora \param{path} indichi una directory. Inoltre perché la funzione abbia
-successo la ACL dovrà essere valida, e contenere tutti le voci necessarie,
-unica eccezione è quella in cui si specifica una ACL vuota per cancellare la
-ACL di default associata a \func{path}.\footnote{questo però è una estensione
- della implementazione delle ACL di Linux, la bozza di standard POSIX.1e
- prevedeva l'uso della apposita funzione \funcd{acl\_delete\_def\_file}, che
- prende come unico argomento il pathname della directory di cui si vuole
- cancellare l'ACL di default, per i dettagli si ricorra alla pagina di
- manuale.} La seconda funzione che consente di impostare una ACL è
-\funcd{acl\_set\_fd}, ed il suo prototipo è:
+La funzione legge il valore delle \textit{capabilities} associate al processo
+da cui viene invocata, restituendo il risultato tramite il puntatore ad un
+\textit{capabilities state} contenente tutti i dati che provvede ad allocare
+autonomamente e che di nuovo occorrerà liberare con \func{cap\_free} quando
+non sarà più utilizzato.
+
+Se invece si vogliono leggere le \textit{capabilities} di un processo
+specifico occorre usare la funzione \funcd{capgetp}, il cui
+prototipo\footnote{su alcune pagine di manuale la funzione è descritta con un
+ prototipo sbagliato, che prevede un valore di ritorno di tipo \type{cap\_t},
+ ma il valore di ritorno è intero, come si può verificare anche dalla
+ dichiarazione della stessa in \texttt{sys/capability.h}.} è:
\begin{functions}
- \headdecl{sys/types.h}
- \headdecl{sys/acl.h}
+ \headdecl{sys/capability.h}
+
+ \funcdecl{int capgetp(pid\_t pid, cap\_t cap\_d)}
+ Legge le \textit{capabilities} del processo indicato da \param{pid}.
- \funcdecl{int acl\_set\_fd(int fd, acl\_t acl)}
+ \bodydesc{La funzione ritorna 0 in caso di successo e $-1$ in caso di
+ errore, nel qual caso \var{errno} può assumere i valori \errval{EINVAL},
+ \errval{EPERM} o \errval{ENOMEM}.
+ }
+\end{functions}
+%TODO controllare e correggere i codici di errore!!!
- Imposta una ACL su un file descriptor.
+La funzione legge il valore delle \textit{capabilities} del processo indicato
+con l'argomento \param{pid}, e restituisce il risultato nel
+\textit{capabilities state} posto all'indirizzo indicato con l'argomento
+\param{cap\_d}; a differenza della precedente in questo caso il
+\textit{capability state} deve essere stato creato in precedenza. Qualora il
+processo indicato non esista si avrà un errore di \errval{ESRCH}. Gli stessi
+valori possono essere letti direttamente nel filesystem \textit{proc}, nei
+file \texttt{/proc/<pid>/status}; ad esempio per \texttt{init} si otterrà
+qualcosa del tipo:
+\begin{Verbatim}
+...
+CapInh: 0000000000000000
+CapPrm: 00000000fffffeff
+CapEff: 00000000fffffeff
+...
+\end{Verbatim}
- \bodydesc{La funzione restituisce $0$ in caso di successo e $-1$ in caso di
- errore, nel qual caso \var{errno} assumerà uno dei valori:
- \begin{errlist}
- \item[\errcode{EBADF}].
- \item[\errcode{EINVAL}] o \param{acl} non è una ACL valida, o \param{type}
- ha in valore non corretto.
- \item[\errcode{ENOSPC}] non c'è spazio disco sufficiente per contenere i
- dati aggiuntivi della ACL.
- \item[\errcode{ENOTSUP}] si è cercato di impostare una ACL su un file
- contenuto in un filesystem che non supporta le ACL.
- \end{errlist}
- ed inoltre \errval{EBADF}, \errval{EROFS}, \errval{EPERM}.
-}
+Infine per impostare le \textit{capabilities} del processo corrente (non
+esiste una funzione che permetta di cambiare le \textit{capabilities} di un
+altro processo) si deve usare la funzione \funcd{cap\_set\_proc}, il cui
+prototipo è:
+\begin{functions}
+ \headdecl{sys/capability.h}
+
+ \funcdecl{int cap\_set\_proc(cap\_t cap\_p)}
+ Imposta le \textit{capabilities} del processo corrente.
+
+ \bodydesc{La funzione ritorna 0 in caso di successo e $-1$ in caso di
+ errore, nel qual caso \var{errno} può assumere i valori \errval{EINVAL},
+ \errval{EPERM} o \errval{ENOMEM}.
+ }
\end{functions}
-La funzione è del tutto è analoga a \funcd{acl\_set\_file} ma opera
-esclusivamente sui file identificati tramite un file descriptor. Non dovendo
-avere a che fare con directory (e con la conseguente possibilità di avere una
-ACL di default) la funzione non necessita che si specifichi il tipo di ACL,
-che sarà sempre di accesso, e prende come unico argomento, a parte il file
-descriptor, la ACL da impostare.
+La funzione modifica le \textit{capabilities} del processo corrente secondo
+quanto specificato con l'argomento \param{cap\_p}, posto che questo sia
+possibile nei termini spiegati in precedenza (non sarà ad esempio possibile
+impostare capacità non presenti nell'insieme di quelle permesse). In caso di
+successo i nuovi valori saranno effettivi al ritorno della funzione, in caso
+di fallimento invece lo stato delle capacità resterà invariato. Si tenga
+presente che \textsl{tutte} le capacità specificate tramite \param{cap\_p}
+devono essere permesse; se anche una sola non lo è la funzione fallirà, e per
+quanto appena detto, lo stato delle \textit{capabilities} non verrà modificato
+(neanche per le parti eventualmente permesse).
-Le funzioni viste finora operano a livello di una intera ACL, eseguendo in una
-sola volta tutte le operazioni relative a tutte le voci in essa contenuta. In
-generale è possibile modificare un singolo valore all'interno di una singola
-voce direttamente con le funzioni previste dallo standard POSIX.1e. Queste
-funzioni però sono alquanto macchinose da utilizzare per cui è molto più
-semplice operare direttamente sulla rappresentazione testuale. Questo è il
-motivo per non tratteremo nei dettagli dette funzioni, fornendone solo una
-descrizione sommaria; chi fosse interessato potrà ricorrere alle pagina di
-manuale.
+Come esempio di utilizzo di queste funzioni nei sorgenti allegati alla guida
+si è distribuito il programma \texttt{getcap.c}, che consente di leggere le
+\textit{capabilities} del processo corrente\footnote{vale a dire di sé stesso,
+ quando lo si lancia, il che può sembrare inutile, ma serve a mostrarci quali
+ sono le \textit{capabilities} standard che ottiene un processo lanciato
+ dalla riga di comando.} o tramite l'opzione \texttt{-p}, quelle di un
+processo qualunque il cui pid viene passato come parametro dell'opzione.
-Se si vuole operare direttamente sui contenuti di un oggetto di tipo
-\type{acl\_t} infatti occorre fare riferimento alle singole voci tramite gli
-opportuni puntatori di tipo \type{acl\_entry\_t}, che possono essere ottenuti
-dalla funzione \funcd{acl\_get\_entry} (per una voce esistente) o dalla
-funzione \funcd{acl\_create\_entry} per una voce da aggiungere. Nel caso della
-prima funzione si potrà poi ripetere la lettura per ottenere i puntatori alle
-singole voci successive alla prima.
+\begin{figure}[htb]
+ \footnotesize \centering
+ \begin{minipage}[c]{15cm}
+ \includecodesample{listati/getcap.c}
+ \end{minipage}
+ \normalsize
+ \caption{Corpo principale del programma \texttt{getcap.c}.}
+ \label{fig:proc_getcap}
+\end{figure}
-Una volta ottenuti detti puntatori si potrà operare sui contenuti delle singole
-voci; con le funzioni \funcd{acl\_get\_tag\_type}, \funcd{acl\_get\_qualifier},
-\funcd{acl\_get\_permset} si potranno leggere rispettivamente tipo,
-qualificatore e permessi mentre con le corrispondente funzioni
-\funcd{acl\_set\_tag\_type}, \funcd{acl\_set\_qualifier},
-\funcd{acl\_set\_permset} si possono impostare i valori; in entrambi i casi
-vengono utilizzati tipi di dato ad hoc.\footnote{descritti nelle singole
- pagine di manuale.} Si possono poi copiare i valori di una voce da una ACL
-ad un altra con \funcd{acl\_copy\_entry} o eliminare una voce da una ACL con
-\funcd{acl\_delete\_entry}.
+La sezione principale del programma è riportata in fig.~\ref{fig:proc_getcap},
+e si basa su una condizione sulla variabile \var{pid} che se si è usato
+l'opzione \texttt{-p} è impostata (nella sezione di gestione delle opzioni,
+che si è tralasciata) al valore del \textsl{pid} del processo di cui si vuole
+leggere le \textit{capabilities} e nulla altrimenti. Nel primo caso
+(\texttt{\small 1--6}) si utilizza direttamente (\texttt{\small 2})
+\func{cap\_get\_proc} per ottenere lo stato delle capacità del processo, nel
+secondo (\texttt{\small 7--14}) prima si inizializza (\texttt{\small 8}) uno
+stato vuoto e poi (\texttt{\small 9}) si legge il valore delle capacità del
+processo indicato.
-\itindend{Access~Control~List}
+Il passo successivo è utilizzare (\texttt{\small 16}) \func{cap\_to\_text} per
+tradurre in una stringa lo stato, e poi (\texttt{\small 17}) stamparlo; infine
+(\texttt{\small 19--20}) si libera la memoria allocata dalle precedenti
+funzioni con \func{cap\_free} per poi ritornare dal ciclo principale della
+funzione.
+
+\itindend{capabilities}
+% TODO vedi http://lwn.net/Articles/198557/ e
+% http://www.madore.org/~david/linux/newcaps/
+% TODO documentare prctl ...
\subsection{La funzione \func{chroot}}
projects / gapil.git / commitdiff