\begin{figure}[!htb]
\footnotesize \centering
- \begin{minipage}[c]{\textwidth}
+ \begin{minipage}[c]{0.80\textwidth}
\includestruct{listati/file_system_type.h}
\end{minipage}
\normalsize
\begin{figure}[!htb]
\footnotesize \centering
- \begin{minipage}[c]{\textwidth}
+ \begin{minipage}[c]{0.8\textwidth}
\includestruct{listati/inode.h}
\end{minipage}
\normalsize
\hline
\hline
\textsl{\code{create}} & Chiamata per creare un nuovo file (vedi
- sez.~\ref{sec:file_open}).\\
+ sez.~\ref{sec:file_open_close}).\\
\textsl{\code{link}} & Crea un \textit{hard link} (vedi
sez.~\ref{sec:link_symlink_rename}).\\
\textsl{\code{unlink}} & Cancella un \textit{hard link} (vedi
detta funzione.} Questo avviene perché su Linux l'apertura di un file
richiede comunque un'altra operazione che mette in gioco l'omonimo oggetto del
VFS: l'allocazione di una struttura di tipo \kstruct{file} che viene associata
-ad ogni file aperto nel sistema.
-
-I motivi per cui viene usata una struttura a parte sono diversi, anzitutto,
-come illustrato in sez.~\ref{sec:file_fd}, questa è necessaria per le
-operazioni eseguite dai processi con l'interfaccia dei file descriptor; ogni
-processo infatti mantiene il riferimento ad una struttura \kstruct{file} per
-ogni file che ha aperto, ed è tramite essa che esegue le operazioni di I/O.
+ad ogni file aperto nel sistema. I motivi per cui viene usata una struttura a
+parte sono diversi, anzitutto, come illustrato in sez.~\ref{sec:file_fd},
+questa è necessaria per le operazioni eseguite dai processi con l'interfaccia
+dei file descriptor. Ogni processo infatti mantiene il riferimento ad una
+struttura \kstruct{file} per ogni file che ha aperto, ed è tramite essa che
+esegue le operazioni di I/O. Inoltre il kernel mantiene un elenco di tutti i
+file aperti nella \itindex{file~table} \textit{file table}.
Inoltre se le operazioni relative agli \textit{inode} fanno riferimento ad
oggetti posti all'interno di un filesystem e vi si applicano quindi le
\begin{figure}[!htb]
\footnotesize \centering
- \begin{minipage}[c]{\textwidth}
+ \begin{minipage}[c]{0.8\textwidth}
\includestruct{listati/file.h}
\end{minipage}
\normalsize
\textbf{Funzione} & \textbf{Operazione} \\
\hline
\hline
- \textsl{\code{open}} & Apre il file (vedi sez.~\ref{sec:file_open}).\\
+ \textsl{\code{open}} & Apre il file (vedi
+ sez.~\ref{sec:file_open_close}).\\
\textsl{\code{read}} & Legge dal file (vedi sez.~\ref{sec:file_read}).\\
\textsl{\code{write}} & Scrive sul file (vedi
sez.~\ref{sec:file_write}).\\
\textsl{\code{llseek}} & Sposta la posizione corrente sul file (vedi
sez.~\ref{sec:file_lseek}).\\
\textsl{\code{ioctl}} & Accede alle operazioni di controllo
- (vedi sez.~\ref{sec:file_ioctl}).\\
+ (vedi sez.~\ref{sec:file_fcntl_ioctl}).\\
\textsl{\code{readdir}}& Legge il contenuto di una directory (vedi
sez.~\ref{sec:file_dir_read}).\\
\textsl{\code{poll}} & Usata nell'I/O multiplexing (vedi
tutte le directory del filesystem, ma su alcuni filesystem è possibile
impostarla a livello di singole directory o per i sottorami di una directory
con il comando \cmd{chattr}.\footnote{questo avviene tramite delle opportune
- \texttt{ioctl} (vedi sez.~\ref{sec:file_ioctl}).}
+ \texttt{ioctl} (vedi sez.~\ref{sec:file_fcntl_ioctl}).}
Questo consente di ridurre al minimo il rischio di perdita dei dati delle
directory in caso di crollo improvviso del sistema, al costo di una certa
\item[\const{MS\_SYNCHRONOUS}] Abilita la scrittura sincrona richiedendo che
ogni modifica al contenuto del filesystem venga immediatamente registrata su
disco. Lo stesso comportamento può essere ottenuto con il flag
- \const{O\_SYNC} di \func{open} (vedi sez.~\ref{sec:file_open}).
+ \const{O\_SYNC} di \func{open} (vedi sez.~\ref{sec:file_open_close}).
Questa opzione consente di ridurre al minimo il rischio di perdita dei dati
in caso di crollo improvviso del sistema, al costo di una pesante perdita di
\end{funcproto}
\footnotetext{più precisamente la \itindex{capabilities} capacità
- \texttt{CAP\_SYS\_ADMIN}.}
+ \const{CAP\_SYS\_ADMIN}, vedi sez.~\ref{sec:proc_capabilities}.}
La funzione prende il nome della directory su cui il filesystem è montato e
non il file o il dispositivo che è stato montato,\footnote{questo è vero a
\textbf{Costante} & \textbf{Descrizione}\\
\hline
\hline
- \const{MNT\_FORCE} & forza lo smontaggio del filesystem anche se questo è
+ \const{MNT\_FORCE} & Forza lo smontaggio del filesystem anche se questo è
occupato (presente dai kernel della serie 2.2).\\
- \const{MNT\_DETACH} & esegue uno smontaggio ``\textsl{pigro}'', in cui si
+ \const{MNT\_DETACH} & Esegue uno smontaggio ``\textsl{pigro}'', in cui si
blocca l'accesso ma si aspetta che il filesystem si
liberi (presente dal kernel 2.4.11 e dalla
\acr{glibc} 2.11).\\
- \const{MNT\_EXPIRE} & se non occupato marca un \itindex{mount~point}
+ \const{MNT\_EXPIRE} & Se non occupato marca un \itindex{mount~point}
\textit{mount point} come ``\textsl{in scadenza}'' in
modo che ad una successiva chiamata senza utilizzo
del filesystem questo venga smontato (presente dal
kernel 2.6.8 e dalla \acr{glibc} 2.11).\\
- \const{UMOUNT\_NOFOLLOW}& non dereferenzia \param{target} se questo è un
+ \const{UMOUNT\_NOFOLLOW}& Non dereferenzia \param{target} se questo è un
collegamento simbolico (vedi
sez.~\ref{sec:link_symlink_rename}) evitando
problemi di sicurezza (presente dal kernel 2.6.34).\\
\begin{figure}[!htb]
\footnotesize \centering
- \begin{minipage}[c]{\textwidth}
+ \begin{minipage}[c]{0.8\textwidth}
\includestruct{listati/statfs.h}
\end{minipage}
\normalsize
Windows o i nomi logici del VMS, che permettono di fare riferimento allo
stesso file chiamandolo con nomi diversi o accedendovi da directory diverse.
Questo è possibile anche in ambiente Unix, dove un nome alternativo viene
-usualmente chiamato `` \textsl{collegamento}'' (o \textit{link}). Data
+usualmente chiamato ``\textsl{collegamento}'' (o \textit{link}). Data
l'architettura del sistema riguardo la gestione dei file vedremo però che ci
sono due metodi sostanzialmente diversi per fare questa operazione.
con i file descriptor (che tratteremo nel prossimo capitolo), in quanto la
risoluzione del collegamento simbolico viene in genere effettuata dalla
funzione che restituisce il file descriptor (normalmente la \func{open}, vedi
-sez.~\ref{sec:file_open}) e tutte le operazioni seguenti fanno riferimento
-solo a quest'ultimo.
+sez.~\ref{sec:file_open_close}) e tutte le operazioni seguenti fanno
+riferimento solo a quest'ultimo.
Dato che, come indicato in tab.~\ref{tab:file_symb_effect}, funzioni come la
\func{open} seguono i collegamenti simbolici, occorrono funzioni apposite per
lo spazio occupato su disco viene liberato. Si tenga presente comunque che a
questo si aggiunge sempre un'ulteriore condizione e cioè che non ci siano
processi che abbiano il suddetto file aperto.\footnote{come vedremo in
- cap.~\ref{cha:file_unix_interface} il kernel mantiene anche una tabella dei
+ sez.~\ref{sec:file_unix_interface} il kernel mantiene anche una tabella dei
file aperti nei vari processi, che a sua volta contiene i riferimenti agli
\itindex{inode} \textit{inode} ad essi relativi; prima di procedere alla
cancellazione dello spazio occupato su disco dal contenuto di un file il
Ma se la scrittura e l'aggiornamento dei dati delle directory è compito del
kernel, sono molte le situazioni in cui i processi necessitano di poterne
leggere il contenuto. Benché questo possa essere fatto direttamente (vedremo
-in sez.~\ref{sec:file_open} che è possibile aprire una directory come se fosse
-un file, anche se solo in sola lettura) in generale il formato con cui esse
-sono scritte può dipendere dal tipo di filesystem, tanto che, come riportato
-in tab.~\ref{tab:file_file_operations}, il \itindex{Virtual~File~System} VFS
-prevede una apposita funzione per la lettura delle directory.
+in sez.~\ref{sec:file_open_close} che è possibile aprire una directory come se
+fosse un file, anche se solo in sola lettura) in generale il formato con cui
+esse sono scritte può dipendere dal tipo di filesystem, tanto che, come
+riportato in tab.~\ref{tab:file_file_operations}, il
+\itindex{Virtual~File~System} VFS prevede una apposita funzione per la lettura
+delle directory.
\itindbeg{directory~stream}
che ha introdotto una apposita interfaccia per la lettura delle directory,
basata sui cosiddetti \textit{directory stream}, chiamati così per l'analogia
con i \textit{file stream} dell'interfaccia standard ANSI C che vedremo in
-cap.~\ref{cha:files_std_interface}. La prima funzione di questa interfaccia è
+sez.~\ref{sec:files_std_interface}. La prima funzione di questa interfaccia è
\funcd{opendir}, il cui prototipo è:
\begin{funcproto}{
\begin{figure}[!htb]
\footnotesize \centering
- \begin{minipage}[c]{\textwidth}
+ \begin{minipage}[c]{0.8\textwidth}
\includestruct{listati/dirent.c}
\end{minipage}
\normalsize
della parte iniziale della struttura, basterà sommarci la dimensione massima
dei nomi dei file nel filesystem che si sta usando, che si può ottenere
attraverso la funzione \func{pathconf} (per la quale si rimanda a
-sez.~\ref{sec:sys_pathconf}) più un ulteriore carattere per la terminazione
-della stringa.
+sez.~\ref{sec:sys_file_limits}) più un ulteriore carattere per la terminazione
+della stringa.
Per quanto riguarda il significato dei campi opzionali, il campo \var{d\_type}
indica il tipo di file (se fifo, directory, collegamento simbolico, ecc.), e
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 stati i creatori del file, i cui permessi (si veda
+sez.~\ref{sec:file_open_close}), in questo modo al ritorno della funzione si
+ha la 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 dalla \acr{glibc} 2.0.7, le versioni precedenti della \acr{glibc} e
più gli altri eventuali codici di errore di \func{mkdir}.}
\end{funcproto}
-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.
+La funzione crea una directory temporanea il cui nome è ottenuto sostituendo
+le \code{XXXXXX} finali di \param{template} con permessi \code{0700} (si veda
+sez.~\ref{sec:file_perm_overview} per i dettagli). Dato che la creazione della
+directory è sempre esclusiva i precedenti problemi di \itindex{race~condition}
+\textit{race condition} non si pongono.
\begin{figure}[!htb]
\footnotesize
\centering
- \begin{minipage}[c]{\textwidth}
+ \begin{minipage}[c]{0.8\textwidth}
\includestruct{listati/stat.h}
\end{minipage}
\normalsize
Benché la descrizione dei commenti di fig.~\ref{fig:file_stat_struct} sia
abbastanza chiara, vale la pena illustrare maggiormente il significato dei
-campi di \structd{stat} su cui non torneremo in maggior dettaglio nel resto di
+campi di \struct{stat} su cui non torneremo in maggior dettaglio nel resto di
questa sezione:
\begin{itemize*}
\textbf{Macro} & \textbf{Tipo del file} \\
\hline
\hline
- \macro{S\_ISREG}\texttt{(m)} & file normale.\\
- \macro{S\_ISDIR}\texttt{(m)} & directory.\\
- \macro{S\_ISCHR}\texttt{(m)} & dispositivo a caratteri.\\
- \macro{S\_ISBLK}\texttt{(m)} & dispositivo a blocchi.\\
- \macro{S\_ISFIFO}\texttt{(m)} & fifo.\\
- \macro{S\_ISLNK}\texttt{(m)} & collegamento simbolico.\\
- \macro{S\_ISSOCK}\texttt{(m)} & socket.\\
+ \macro{S\_ISREG}\texttt{(m)} & File normale.\\
+ \macro{S\_ISDIR}\texttt{(m)} & Directory.\\
+ \macro{S\_ISCHR}\texttt{(m)} & Dispositivo a caratteri.\\
+ \macro{S\_ISBLK}\texttt{(m)} & Dispositivo a blocchi.\\
+ \macro{S\_ISFIFO}\texttt{(m)} & Fifo.\\
+ \macro{S\_ISLNK}\texttt{(m)} & Collegamento simbolico.\\
+ \macro{S\_ISSOCK}\texttt{(m)} & Socket.\\
\hline
\end{tabular}
\caption{Macro per i tipi di file (definite in \headfile{sys/stat.h}).}
\const{S\_IFCHR} & 0020000 & Dispositivo a caratteri.\\
\const{S\_IFIFO} & 0010000 & Fifo.\\
\hline
- \const{S\_ISUID} & 0004000 & \itindex{suid~bit} \acr{suid} bit.\\
- \const{S\_ISGID} & 0002000 & \itindex{sgid~bit} \acr{sgid} bit.\\
- \const{S\_ISVTX} & 0001000 & \itindex{sticky~bit} \acr{sticky} bit.\\
+ \const{S\_ISUID} & 0004000 & Set user ID \itindex{suid~bit} (\acr{suid})
+ bit.\\
+ \const{S\_ISGID} & 0002000 & Set group ID \itindex{sgid~bit}
+ (\acr{sgid}) bit.\\
+ \const{S\_ISVTX} & 0001000 & \itindex{sticky~bit} \acr{Sticky} bit.\\
\hline
\const{S\_IRWXU} & 00700 & Maschera per i permessi del proprietario.\\
\const{S\_IRUSR} & 00400 & Il proprietario ha permesso di lettura.\\
\begin{figure}[!htb]
\footnotesize \centering
- \begin{minipage}[c]{\textwidth}
+ \begin{minipage}[c]{0.8\textwidth}
\includestruct{listati/utimbuf.h}
\end{minipage}
\normalsize
proprietari del file o avere i privilegi di amministratore. Se invece si è
specificato un valore diverso la funzione avrà successo solo se si è
proprietari del file o se si hanno i privilegi di amministratore.\footnote{per
- essere precisi la \itindex{capabilities} capacità \const{CAP\_FOWNER}.} In
-entrambi i casi per verificare la proprietà del file viene utilizzato
-l'\ids{UID} effettivo del processo.
+ essere precisi la \itindex{capabilities} capacità \const{CAP\_FOWNER}, vedi
+ sez.~\ref{sec:proc_capabilities}.} In entrambi i casi per verificare la
+proprietà del file viene utilizzato l'\ids{UID} effettivo del processo.
Si tenga presente che non è possibile modificare manualmente il tempo di
cambiamento di stato del file, che viene aggiornato direttamente dal kernel
\begin{figure}[!htb]
\footnotesize \centering
- \begin{minipage}[c]{\textwidth}
+ \begin{minipage}[c]{0.8\textwidth}
\includestruct{listati/timeval.h}
\end{minipage}
\normalsize
\begin{figure}[!htb]
\footnotesize \centering
- \begin{minipage}[c]{\textwidth}
+ \begin{minipage}[c]{0.8\textwidth}
\includestruct{listati/timespec.h}
\end{minipage}
\normalsize
state aggiunte ai filesystem standard con opportune estensioni (vedi
sez.~\ref{sec:file_ACL}) per arrivare a meccanismi di controllo ancora più
sofisticati come il \itindex{Mandatory~Access~Control~(MAC)}
- \textit{mandatory access control} di SE-Linux e delle altre estesioni come
- \textit{Smack} o.} ma nella maggior parte dei casi il meccanismo standard è
-più che sufficiente a soddisfare tutte le necessità più comuni. I tre
-permessi di base associati ad ogni file sono:
+ \textit{mandatory access control} di SE-Linux e delle altre estensioni come
+ \textit{Smack} o \textit{AppArmor}.} ma nella maggior parte dei casi il
+meccanismo standard è più che sufficiente a soddisfare tutte le necessità più
+comuni. I tre permessi di base associati ad ogni file sono:
\begin{itemize*}
\item il permesso di lettura (indicato con la lettera \texttt{r}, dall'inglese
\textit{read}).
di scrittura per la directory.
Avere il permesso di lettura per un file consente di aprirlo con le opzioni
-(si veda quanto riportato in tab.~\ref{tab:file_open_flags}) di sola lettura o
+(si veda quanto riportato in sez.~\ref{sec:file_open_close}) di sola lettura o
di lettura/scrittura e leggerne il contenuto. Avere il permesso di scrittura
consente di aprire un file in sola scrittura o lettura/scrittura e modificarne
il contenuto, lo stesso permesso è necessario per poter troncare il file o per
potrà cancellare, rinominare, o modificare nei permessi o nelle altre
proprietà.
-Entrambi questi attributi attivano queste restrizioni a livello di filesytem,
+Entrambi questi attributi attivano queste restrizioni a livello di filesystem,
per cui a differenza dei permessi ordinari esse varranno per qualunque utente
compreso l'amministratore. L'amministratore è l'unico che può attivare o
disattivare questi attributi,\footnote{più precisamente un processo con la
- \itindex{capabilities} capacità \const{CAP\_LINUX\_IMMUTABLE}.} e potendo
-rimuoverli è comunque capace di tornare in grado di eseguire qualunque
-operazione su un file immutabile o \textit{append-only}.
+ \itindex{capabilities} capacità \const{CAP\_LINUX\_IMMUTABLE}, vedi
+ sez.~\ref{sec:proc_capabilities}.} e potendo rimuoverli è comunque capace di
+tornare in grado di eseguire qualunque operazione su un file immutabile o
+\textit{append-only}.
\itindend{file~attributes}
\textbf{\param{mode}} & \textbf{Valore} & \textbf{Significato} \\
\hline
\hline
- \const{S\_ISUID} & 04000 & Set user ID \itindex{suid~bit}.\\
- \const{S\_ISGID} & 02000 & Set group ID \itindex{sgid~bit}.\\
- \const{S\_ISVTX} & 01000 & Sticky bit \itindex{sticky~bit}.\\
+ \const{S\_ISUID} & 04000 & Set user ID \itindex{suid~bit} bit.\\
+ \const{S\_ISGID} & 02000 & Set group ID \itindex{sgid~bit} bit.\\
+ \const{S\_ISVTX} & 01000 & Sticky \itindex{sticky~bit} bit.\\
\hline
\const{S\_IRWXU} & 00700 & L'utente ha tutti i permessi.\\
\const{S\_IRUSR} & 00400 & L'utente ha il permesso di lettura.\\
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
quando il file viene creato. Le funzioni dell'interfaccia nativa di Unix, come
-vedremo in sez.~\ref{sec:file_open}, permettono di indicare esplicitamente i
-permessi di creazione di un file, ma questo non è possibile per le funzioni
-dell'interfaccia standard ANSI C che non prevede l'esistenza di utenti e
-gruppi, ed inoltre il problema si pone anche per l'interfaccia nativa quando i
-permessi non vengono indicati esplicitamente.
+vedremo in sez.~\ref{sec:file_open_close}, permettono di indicare
+esplicitamente i permessi di creazione di un file, ma questo non è possibile
+per le funzioni dell'interfaccia standard ANSI C che non prevede l'esistenza
+di utenti e gruppi, ed inoltre il problema si pone anche per l'interfaccia
+nativa quando i permessi non vengono indicati esplicitamente.
\itindbeg{umask}
\subsection{La gestione della titolarità dei file}
\label{sec:file_ownership_management}
-Vedremo in sez.~\ref{sec:file_base_func} con quali funzioni si possono creare
+Vedremo in sez.~\ref{sec:file_open_close} con quali funzioni si possono creare
nuovi file, in tale occasione vedremo che è possibile specificare in sede di
creazione quali permessi applicare ad un file, però non si può indicare a
quale utente e gruppo esso deve appartenere. Lo stesso problema si presenta
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 abbiam chiamato genericamente \textsl{metadati}) che però non
+(quelli che abbiamo chiamato genericamente \textsl{metadati}) che però non
potevano trovare spazio nei dati classici mantenuti negli \itindex{inode}
\textit{inode}.
Le tre funzioni rimuovono un attributo esteso operando rispettivamente su di
un file, su un collegamento simbolico o un file descriptor, che vengono
specificati dal valore passato con il loro primo argomento. L'attributo da
-rimuovere deve essere anchein questo caso indicato con
+rimuovere deve essere anche in questo caso indicato con
l'argomento \param{name} secondo le stesse modalità già illustrate in
precedenza per le altre funzioni relative alla gestione degli attributi
estesi.
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
+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
\textbf{Tipo} & \textbf{Descrizione} \\
\hline
\hline
- \const{ACL\_USER\_OBJ} & voce che contiene i diritti di accesso del
+ \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
+ \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
+ \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
+ \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
+ \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
+ \const{ACL\_OTHER} & Voce che contiene i diritti di accesso di chi
non corrisponde a nessuna altra voce dell'ACL.\\
\hline
\end{tabular}
\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
+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
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},
+ordinari vengono mappati nelle 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 e viceversa.\footnote{per permessi
\const{ACL\_OTHER}, nel caso di \const{ACL\_GROUP\_OBJ} questo vale soltanto
se non è presente una voce di tipo \const{ACL\_MASK}, che è quanto avviene
normalmente se non sono presenti ACL aggiuntive rispetto ai permessi
-ordinari.za Se invece questa è presente verranno tolti dai permessi di
+ordinari. Se invece questa è presente verranno tolti dai permessi di
\const{ACL\_GROUP\_OBJ} (cioè dai permessi per il gruppo proprietario del
file) tutti quelli non presenti in \const{ACL\_MASK}.\footnote{questo diverso
comportamento a seconda delle condizioni è stato introdotto dalla
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
+ \func{creat} (vedi sez.~\ref{sec:file_open_close}), \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 andrà a contenerli.
+presenza di una \textit{Default ACL} sulla directory che andrà a contenerli.
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
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à, in questa come in tutte le funzioni seguenti che restituiscono un
-oggetto di tipo \type{acl\_t}, confrontare il valore di ritorno della funzione
-con ``\code{(acl\_t) NULL}''.\footnote{dato che il valore \var{NULL} in questo
- caso viene restituito come oggetto di tipo \type{acl\_t}, un confronto del
- risultato della funzione con \var{NULL} darebbe un errore di compilazione
- per la differenza di tipo.}
+di tipo ``\code{(acl\_t) NULL}'' e si dovrà, in questa come in tutte le
+funzioni seguenti che restituiscono un oggetto di tipo \type{acl\_t},
+confrontare il valore di ritorno della funzione con \val{NULL}.\footnote{a
+ voler essere estremamente pignoli si dovrebbe usare ``\code{(acl\_t)
+ NULL}'', ma è sufficiente fare un confronto direttamente con \val{NULL}
+ essendo cura del compilatore fare le conversioni necessarie.}
Una volta che si siano completate le operazioni sui dati di una ACL la memoria
allocata per un oggetto \type{acl\_t} dovrà essere liberata esplicitamente
\begin{funcproto}{
\fhead{sys/types.h}
\fhead{sys/acl.h}
-\fdecl{int acl\_free(void * obj\_p)}
+\fdecl{int acl\_free(void *obj\_p)}
\fdesc{Disalloca la memoria riservata per una ACL.}
}
{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
- caso \var{errno} assumerà il valore:
+ caso \var{errno} può assumere solo il valore:
\begin{errlist}
\item[\errcode{EINVAL}] \param{obj\_p} non è valido.
\end{errlist}
*}'', 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 della una voce di una ACL.
-
-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} ci sono molte altre funzioni che
-possono allocare memoria per i dati delle ACL, è pertanto opportuno tenere
-traccia di tutte le chiamate a queste funzioni perché alla fine delle
-operazioni tutta la memoria allocata dovrà essere liberata con
+qualificatori della una voce di una ACL. L'uso del tipo generico ``\ctyp{void
+ *}'' consente di evitare di eseguire un \textit{cast} al tipo di dato di cui
+si vuole effettuare la disallocazione.
+
+Si tenga presente poi che oltre a \func{acl\_init} ci sono molte altre
+funzioni che possono allocare memoria per i dati delle ACL, è pertanto
+opportuno tenere traccia di tutte le chiamate a 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
}
{La funzione ritorna un oggetto di tipo \type{acl\_t} in caso di successo e
- \val{NULL} per un errore, nel qual caso \var{errno} potra assumere
- solo il valore \errval{ENOMEM} nel suo significato generico.}
+ \val{NULL} per un errore, nel qual caso \var{errno} può assumere solo
+ il valore \errval{ENOMEM}.}
\end{funcproto}
semplificare l'inizializzazione in maniera molto comoda.
Altre due funzioni che consentono di creare una ACL già inizializzata sono
-\funcd{acl\_get\_fd} e \funcd{acl\_get\_file}, che però sono per lo più
-utilizzate per leggere la ACL corrente di un file; i rispettivi prototipi
-sono:
+\funcd{acl\_get\_fd} e \funcd{acl\_get\_file}, che consentono di leggere la
+ACL di un file; i rispettivi prototipi sono:
\begin{funcproto}{
\fhead{sys/types.h}
\fhead{sys/acl.h}
\fdecl{acl\_t acl\_get\_file(const char *path\_p, acl\_type\_t type)}
\fdecl{acl\_t acl\_get\_fd(int fd)}
-\fdesc{Ottiene i dati delle ACL di un file.}
+\fdesc{Leggono i dati delle ACL di un file.}
}
-{La funzione ritorna un oggetto di tipo \type{acl\_t} in caso di successo e
- \val{NULL} per un errore, nel qual caso \var{errno} assumerà uno
- dei valori:
+{Le funzioni ritornano un oggetto di tipo \type{acl\_t} in caso di successo e
+ \val{NULL} per un 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{ACCESS}] non c'è accesso per una componente di
+ \param{path\_p} o si è richiesta una ACL di default per un file (solo per
+ \func{acl\_get\_file}).
+ \item[\errcode{EINVAL}] \param{type} non ha un valore valido (solo per
+ \func{acl\_get\_file}).
\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}. }
+ ed inoltre \errval{ENOMEM} per entrambe, \errval{EBADF} per
+ \func{acl\_get\_fd}, e \errval{ENAMETOOLONG}, \errval{ENOENT},
+ \errval{ENOTDIR}, per \func{acl\_get\_file} nel loro significato generico. }
\end{funcproto}
Le due funzioni ritornano, con un oggetto di tipo \type{acl\_t}, il valore
\item[\errcode{EINVAL}] la rappresentazione testuale all'indirizzo
\param{buf\_p} non è valida.
\end{errlist}
- ed inoltre
-nel loro significato generico.}
+}
\end{funcproto}
La funzione prende come argomento il puntatore ad un buffer dove si è inserita
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.}
+ l'assenza del permesso.}
+
+Un possibile esempio di rappresentazione della ACL di un file ordinario a cui,
+oltre ai permessi ordinari, si è aggiunto un altro utente con un accesso in
+lettura, è il seguente:
+\begin{Example}
+user::rw-
+group::r--
+other::r--
+user:piccardi:r--
+\end{Example}
Va precisato che i due tipi \texttt{user} e \texttt{group} sono usati
rispettivamente per indicare delle voci relative ad utenti e
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 è:
+testuale di una ACL, sono invece disponibili due funzioni. La prima delle due,
+di uso più immediato, è \funcd{acl\_to\_text}, ed il suo prototipo è:
\begin{funcproto}{
\fhead{sys/types.h}
\fhead{sys/acl.h}
-\fdecl{char * acl\_to\_text(acl\_t acl, ssize\_t *len\_p)}
+\fdecl{char *acl\_to\_text(acl\_t acl, ssize\_t *len\_p)}
\fdesc{Produce la rappresentazione testuale di una ACL.}
}
\textit{value result argument}) la dimensione della stringa con la
rappresentazione testuale, non comprendente il carattere nullo finale.
-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 è:
+La seconda funzione, che permette di controllare con una gran dovizia di
+particolari la generazione della stringa contenente la rappresentazione
+testuale della ACL, è \funcd{acl\_to\_any\_text}, ed il suo prototipo è:
+
\begin{funcproto}{
\fhead{sys/types.h}
\fhead{sys/acl.h}
-\fdecl{char * acl\_to\_any\_text(acl\_t acl, const char *prefix, char
+\fdecl{char *acl\_to\_any\_text(acl\_t acl, const char *prefix, char
separator, int options)}
\fdesc{Produce la rappresentazione testuale di una ACL.}
}
\textbf{Tipo} & \textbf{Descrizione} \\
\hline
\hline
- \const{TEXT\_ABBREVIATE} & stampa le voci in forma abbreviata.\\
+ \const{TEXT\_ABBREVIATE} & Stampa le voci in forma abbreviata.\\
\const{TEXT\_NUMERIC\_IDS} & non effettua la risoluzione numerica di
\ids{UID} e \ids{GID}.\\
- \const{TEXT\_SOME\_EFFECTIVE}& per ciascuna voce che contiene permessi che
+ \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
+ \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
+ \const{TEXT\_SMART\_INDENT} & Da usare in combinazione con le precedenti
+ opzioni \const{TEXT\_SOME\_EFFECTIVE} e
+ \const{TEXT\_ALL\_EFFECTIVE}, aumenta
automaticamente il numero di spaziatori
prima degli eventuali commenti in modo da
mantenerli allineati.\\
{La funzione ritorna la dimensione in byte della rappresentazione binaria
della ACL in caso di successo e $-1$ per un errore, nel qual caso
- \var{errno} assumerà uno dei valori:
+ \var{errno} può assumere solo il valore:
\begin{errlist}
\item[\errcode{EINVAL}] la ACL indicata da \param{acl} non è valida.
\end{errlist}
}
\end{funcproto}
-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,
-in questo caso con \func{free}.
-
-La funzione che consente di leggere la rappresentazione binaria di una ACL è
-\funcd{acl\_copy\_ext}, il cui prototipo è:
+Ottenuta con \func{acl\_size} la dimensione per il buffer di una ACL lo si
+potrà allocare direttamente con \func{malloc}. La rappresentazione binaria di
+una ACL si potrà invece ottenere con la funzione \funcd{acl\_copy\_ext}, il
+cui prototipo è:
\begin{funcproto}{
\fhead{sys/types.h}
}
\end{funcproto}
-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 scriverà la rappresentazione binaria della ACL indicata da
+\param{acl} sul buffer di dimensione \param{size}
+all'indirizzo \param{buf\_p}, 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 è:
+Viceversa se si vuole ripristinare una ACL a partire da una rappresentazione
+binaria si potrà usare la funzione \funcd{acl\_copy\_int}, il cui prototipo è:
\begin{funcproto}{
\fhead{sys/types.h}
\fhead{sys/acl.h}
\fdecl{acl\_t acl\_copy\_int(const void *buf\_p)}
-\fdesc{.}
+\fdesc{Ripristina la rappresentazione binaria di una ACL.}
}
{La funzione ritorna un oggetto di tipo \type{acl\_t} in caso di successo e
}
\end{funcproto}
-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 alloca autonomamente un oggetto di tipo \type{acl\_t}, restituito
+come valore di ritorno, con il contenuto della ACL rappresentata dai dati del
+buffer puntato da \param{buf\_p}. Al solito 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
directory, ed il cui prototipo è:
\begin{funcproto}{
-\fhead{sys/types.}
+\fhead{sys/types.h}
\fhead{sys/acl.h}
\fdecl{int acl\_set\_file(const char *path, acl\_type\_t type, acl\_t acl)}
\fdesc{Imposta una ACL su un file o una directory.}
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 \funcm{acl\_copy\_entry} o eliminare una voce da una ACL con
-\funcm{acl\_delete\_entry}.
+\funcm{acl\_delete\_entry} e verificarne la validità prima di usarla con
+\funcm{acl\_valid} o \funcm{acl\_check}.
\itindend{Access~Control~List~(ACL)}
+Come esempio di utilizzo di queste funzioni nei sorgenti allegati alla guida
+si è distribuito il programma \texttt{mygetfacl.c}, che consente di leggere le
+ACL di un file, passato come argomento.
+
+\begin{figure}[!htbp]
+ \footnotesize \centering
+ \begin{minipage}[c]{\codesamplewidth}
+ \includecodesample{listati/mygetfacl.c}
+ \end{minipage}
+ \normalsize
+ \caption{Corpo principale del programma \texttt{mygetfacl.c}.}
+ \label{fig:proc_mygetfacl}
+\end{figure}
+
+La sezione principale del programma, da cui si è rimossa la sezione sulla
+gestione delle opzioni, è riportata in fig.~\ref{fig:proc_mygetfacl}. Il
+programma richiede un unico argomento (\texttt{\small 16--20}) che indica il
+file di cui si vuole leggere la ACL. Se questo è presente si usa
+(\texttt{\small 22}) la funzione \func{get\_acl\_file} per leggerne la ACL, e
+si controlla (\texttt{\small 23--26}) se l'operazione ha successo, uscendo con
+un messaggio di errore in caso contrario.
+
+Ottenuta la ACL la si converte in formato testuale (\texttt{\small 27}) con la
+funzione \func{acl\_to\_text}, controllando di nuovo se l'operazione ha
+successo (\texttt{\small 28--31}) ed uscendo in caso contrario. Si provvede
+infine a stampare la rappresentazione testuale (\texttt{\small 32}) e dopo
+aver liberato (\texttt{\small 33--34}) le risorse allocate automaticamente, si
+conclude l'esecuzione.
+
\subsection{La gestione delle quote disco}
\label{sec:disk_quota}
-Quella delle quote disco è una funzionalità introdotta inizialmente da BSD, e
+Quella delle quote disco è una funzionalità introdotta inizialmente da BSD e
presente in Linux fino dai kernel dalla serie 2.0, che consente di porre dei
tetti massimi al consumo delle risorse di un filesystem (spazio disco e
-\itindex{inode} \textit{inode}) da parte di utenti e gruppi. Dato che la
-funzionalità ha senso solo per i filesystem su cui si mantengono i dati degli
-utenti\footnote{in genere la si attiva sul filesystem che contiene le
- \textit{home} degli utenti, dato che non avrebbe senso per i file di sistema
- che in genere appartengono all'amministratore.} essa deve essere
-esplicitamente richiesta; questo si fa tramite due distinte opzioni di
-montaggio, \texttt{usrquota} e \texttt{grpquota} che abilitano le quote
-rispettivamente per gli utenti e per i gruppi. Grazie a questo è possibile
-usare le limitazioni sulle quote solo sugli utenti o solo sui gruppi.
+\itindex{inode} \textit{inode}) da parte di utenti e gruppi.
+
+Dato che la funzionalità ha senso solo per i filesystem su cui si mantengono i
+dati degli utenti\footnote{in genere la si attiva sul filesystem che contiene
+ le \textit{home} degli utenti, dato che non avrebbe senso per i file di
+ sistema che in genere appartengono all'amministratore.} essa deve essere
+attivata esplicitamente. Questo si fa, per tutti i filesystem che le
+supportano, tramite due distinte opzioni di montaggio, \texttt{usrquota} e
+\texttt{grpquota} che abilitano le quote rispettivamente per gli utenti e per
+i gruppi. Così è possibile usare le limitazioni sulle quote o sugli utenti o
+sui gruppi o su entrambi.
Il meccanismo prevede che per ciascun filesystem che supporta le quote disco
(i vari \textit{extN}, \textit{btrfs}, \textit{XFS}, \textit{JFS},
\textit{ReiserFS}) il kernel provveda sia a mantenere aggiornati i dati
-relativi al consumo delle risorse da parte di utenti e/o gruppi che a far
-rispettare i limiti imposti dal sistema, con la generazione di un errore di
-\errval{EDQUOT} per tutte le operazioni sui file che porterebbero ad un
+relativi al consumo delle risorse da parte degli utenti e dei gruppi, che a
+far rispettare i limiti imposti dal sistema, con la generazione di un errore
+di \errcode{EDQUOT} per tutte le operazioni sui file che porterebbero ad un
superamento degli stessi. Si tenga presente che questi due compiti sono
-separati, il primo si attiva al montaggio del filesystem con le quote
-attivate, il secondo deve essere abilitato esplicitamente.
+separati, il primo si attiva al montaggio del filesystem con il supporto per
+le quote, il secondo deve essere abilitato esplicitamente.
Per il mantenimento dei dati di consumo delle risorse vengono usati due file
-riservati (uno per le quote utente e l'altro per le quote gruppo) nella
-directory radice del filesystem su cui si sono attivate le quote;\footnote{la
- cosa vale per tutti i filesystem tranne \textit{XFS} che mantiene i dati
- internamente.} con la versione 2 del supporto delle quote, l'unica rimasta
-in uso, questi file sono \texttt{aquota.user} e \texttt{aquota.group}, in
-precedenza erano \texttt{quota.user} e \texttt{quota.group}. Dato che i file
-vengono aggiornati soltanto se il filesystem è stato montato con il supporto
-delle quote, se si abilita questo in un secondo tempo (o se si eseguono
-operazioni sul filesystem senza averlo abilitato) i dati contenuti possono non
-corrispondere esattamente allo stato corrente del consumo delle risorse; per
-questo in genere prima di montare in scrittura un filesystem su cui sono
-abilitate le quote in genere viene utilizzato il comando \cmd{quotacheck} per
-verificare e aggiornare i dati.
-
-Le restrizioni sul consumo delle risorse prevedono due limiti, il primo viene
-detto \textit{soft limit} e può essere superato per brevi periodi di tempo, il
-secondo viene detto \textit{hard limit} non può mai essere superato. Il
-periodo di tempo per cui è possibile superare il \textit{soft limit} è detto
-``\textsl{periodo di grazia}'' (\textit{grace period}), passato questo tempo
-il passaggio del \textit{soft limit} viene trattato allo stesso modo
-dell'\textit{hard limit}. Questi limiti riguardano separatamente sia lo
-spazio disco (i blocchi) che il numero di file (gli \itindex{inode}
-\textit{inode}) e devono pertanto essere specificati per entrambe le risorse.
+riservati nella directory radice del filesystem su cui si sono attivate le
+quote, uno per le quote utente e l'altro per le quote gruppo.\footnote{la cosa
+ vale per tutti i filesystem tranne \textit{XFS} che mantiene i dati
+ internamente.} Con la versione 2 del supporto delle quote, che da anni è
+l'unica rimasta in uso, questi file sono \texttt{aquota.user} e
+\texttt{aquota.group}, in precedenza erano \texttt{quota.user} e
+\texttt{quota.group}.
+
+Dato che questi file vengono aggiornati soltanto se il filesystem è stato
+montato attivando il supporto delle quote, se si abilita il supporto in un
+secondo tempo e nel frattempo sono state eseguite delle operazioni sul
+filesystem quando il supporto era disabilitato, i dati contenuti possono non
+corrispondere esattamente allo stato corrente del consumo delle risorse. Per
+questo motivo prima di montare in scrittura un filesystem su cui sono
+abilitate le quote viene richiesto di utilizzare il comando \cmd{quotacheck}
+per verificare e aggiornare i dati.
+
+Le restrizioni sul consumo delle risorse previste dal sistema delle quote
+prevedono sempre la presenza di due diversi limiti, il primo viene detto
+\textit{soft limit} e può essere superato per brevi periodi di tempo senza che
+causare errori per lo sforamento delle quote, il secondo viene detto
+\textit{hard limit} e non può mai essere superato.
+
+Il periodo di tempo per cui è possibile eccedere rispetto alle restrizioni
+indicate dal \textit{soft limit} è detto ``\textsl{periodo di grazia}''
+(\textit{grace period}), che si attiva non appena si supera la quota da esso
+indicata. Se si continua a restare al di sopra del \textit{soft limit} una
+volta scaduto il \textit{grace period} questo verrà trattato allo stesso modo
+dell'\textit{hard limit} e si avrà l'emissione immediata di un errore.
+
+Si tenga presente infine che entrambi i tipi di limiti (\textit{soft limit} e
+\textit{hard limit}) possono essere disposti separatamente su entrambe le
+risorse di un filesystem, essi cioè possono essere presenti in maniera
+indipendente sia sullo spazio disco, con un massimo per il numero di blocchi,
+che sui file, con un massimo per il numero di \itindex{inode} \textit{inode}.
La funzione di sistema che consente di controllare tutti i vari aspetti della
gestione delle quote è \funcd{quotactl}, ed il suo prototipo è:
quote indicato da \param{addr} non esiste o non è un file ordinario.
\item[\errcode{EBUSY}] si è richiesto \const{Q\_QUOTAON}, ma le quote sono
già attive.
- \item[\errcode{EFAULT}] l'indirizzo \param{addr} non è valido.
+ \item[\errcode{EFAULT}] \param{addr} non è un puntatore valido.
\item[\errcode{EINVAL}] o \param{cmd} non è un comando valido,
o il dispositivo \param{dev} non esiste.
\item[\errcode{EIO}] errore di lettura/scrittura sul file delle quote.
% TODO rivedere gli errori
-La funzione richiede che il filesystem sul quale si vuole operare sia montato
-con il supporto delle quote abilitato; esso deve essere specificato con il
-nome del file di dispositivo nell'argomento \param{dev}. Per le operazioni che
-lo richiedono inoltre si dovrà indicare con l'argomento \param{id} l'utente o
-il gruppo (specificati rispettivamente per \ids{UID} e \ids{GID}) su cui si
-vuole operare. Alcune operazioni usano l'argomento \param{addr} per indicare
-un indirizzo ad un area di memoria il cui utilizzo dipende dall'operazione
-stessa.
-
-Il tipo di operazione che si intende effettuare deve essere indicato tramite
-il primo argomento \param{cmd}, questo in genere viene specificato con
-l'ausilio della macro \macro{QCMD}:
+La funzione richiede che il filesystem sul quale si vuole operare, che deve
+essere specificato con il nome del relativo file di dispositivo
+nell'argomento \param{dev}, sia montato con il supporto delle quote
+abilitato. Per le operazioni che lo richiedono inoltre si dovrà indicare con
+l'argomento \param{id} l'utente o il gruppo (specificati rispettivamente per
+\ids{UID} e \ids{GID}) su cui si vuole operare, o altri dati relativi
+all'operazione. Alcune operazioni più complesse usano infine
+l'argomento \param{addr} per indicare un indirizzo ad un area di memoria il
+cui utilizzo dipende dall'operazione stessa.
+
+La funzione prevede la possibilità di eseguire una serie operazioni sulle
+quote molto diverse fra loro, la scelta viene effettuata tramite il primo
+argomento, \param{cmd}, che però oltre all'operazione indica anche a quale
+tipo di quota (utente o gruppo) l'operazione deve applicarsi. Per questo il
+valore di questo argomento viene costruito con l'ausilio della di una apposita
+macro \macro{QCMD}:
{\centering
\vspace{3pt}
\end{funcbox}
}
-\noindent che consente di specificare, oltre al tipo di operazione, se questa
-deve applicarsi alle quote utente o alle quote gruppo, nel qual
-caso \param{type} deve essere rispettivamente \const{USRQUOTA} o
+La macro consente di specificare, oltre al tipo di operazione, da indicare con
+l'argomento \param{subcmd} se questa deve applicarsi alle quote utente o alle
+quote gruppo. Questo viene indicato dall'argomento \param{type} che deve
+essere sempre definito ed assegnato ad uno fra i due valori \const{USRQUOTA} o
\const{GRPQUOTA}.
-
\begin{table}[htb]
\centering
\footnotesize
\label{tab:quotactl_commands}
\end{table}
-
-Le diverse operazioni supportate da \func{quotactl}, da indicare con
-l'argomento \param{subcmd} di \macro{QCMD}, sono riportate in
-tab.~\ref{tab:quotactl_commands}. In generale le operazione di attivazione,
-disattivazione e di modifica dei limiti delle quote sono riservate e
-richiedono i privilegi di amministratore.\footnote{per essere precisi tutte le
- operazioni indicate come privilegiate in tab.~\ref{tab:quotactl_commands}
- richiedono la \textit{capability} \const{CAP\_SYS\_ADMIN}.} Inoltre gli
-utenti possono soltanto richiedere i dati relativi alle proprie quote, solo
-l'amministratore può ottenere i dati di tutti.
-
-\begin{table}[htb]
- \centering
- \footnotesize
- \begin{tabular}{|l|p{10cm}|}
- \hline
- \textbf{Identificatore} & \textbf{Descrizione} \\
- \hline
- \hline
- \const{QFMT\_VFS\_OLD}& il vecchio (ed obsoleto) formato delle quote.\\
- \const{QFMT\_VFS\_V0} & la versione 0 usata dal VFS di Linux (supporta
- \ids{UID} e \ids{GID} a 32 bit e limiti fino a
- $2^{42}$ byte e $2^{32}$ file.\\
- \const{QFMT\_VFS\_V1} & la versione 1 usata dal VFS di Linux (supporta
- \ids{UID} e \ids{GID} a 32 bit e limiti fino a
- $2^{64}$ byte e $2^{64}$ file.\\
- \hline
- \end{tabular}
- \caption{Valori di identificazione del formato delle quote.}
- \label{tab:quotactl_id_format}
-\end{table}
-
-Alcuni dei comandi di tab.~\ref{tab:quotactl_commands} sono alquanto complessi
-e richiedono un approfondimento maggiore, in particolare \const{Q\_GETQUOTA} e
-\const{Q\_SETQUOTA} fanno riferimento ad una specifica struttura
-\struct{dqblk}, la cui definizione è riportata in
+I possibili valori per l'argomento \param{subcmd} di \macro{QCMD} sono
+riportati in tab.~\ref{tab:quotactl_commands}, che illustra brevemente il
+significato delle operazioni associate a ciascuno di essi. In generale le
+operazioni di attivazione, disattivazione e di modifica dei limiti delle quote
+sono riservate e richiedono i privilegi di amministratore.\footnote{per essere
+ precisi tutte le operazioni indicate come privilegiate in
+ tab.~\ref{tab:quotactl_commands} richiedono la \textit{capability}
+ \const{CAP\_SYS\_ADMIN}.} Inoltre gli utenti possono soltanto richiedere i
+dati relativi alle proprie quote, solo l'amministratore può ottenere i dati di
+tutti.
+
+
+Alcune delle operazioni di tab.~\ref{tab:quotactl_commands} sono alquanto
+complesse e richiedono un approfondimento maggiore. Le due più rilevanti sono
+probabilmente \const{Q\_GETQUOTA} e \const{Q\_SETQUOTA}, che consentono la
+gestione dei limiti delle quote. Entrambe fanno riferimento ad una specifica
+struttura \struct{dqblk}, la cui definizione è riportata in
fig.~\ref{fig:dqblk_struct},\footnote{la definizione mostrata è quella usata
fino dal kernel 2.4.22, non prenderemo in considerazione le versioni
obsolete.} nella quale vengono inseriti i dati relativi alle quote di un
-singolo utente.
+singolo utente o gruppo.
\begin{figure}[!htb]
\footnotesize \centering
- \begin{minipage}[c]{\textwidth}
+ \begin{minipage}[c]{0.9\textwidth}
\includestruct{listati/dqblk.h}
\end{minipage}
\normalsize
\label{fig:dqblk_struct}
\end{figure}
-La struttura viene usata sia con \const{Q\_GETQUOTA} per ottenere i valori
-correnti dei limiti e dell'occupazione delle risorse, che con
-\const{Q\_SETQUOTA} per effettuare modifiche ai limiti; come si può notare ci
-sono alcuni campi (in sostanza \val{dqb\_curspace}, \val{dqb\_curinodes},
-\val{dqb\_btime}, \val{dqb\_itime}) che hanno senso solo in lettura in quanto
-riportano uno stato non modificabile da \func{quotactl}, come l'uso corrente
-di spazio e \itindex{inode} \textit{inode} o il tempo che resta nel caso si
-sia superato un \textit{soft limit}.
+La struttura \struct{dqblk} viene usata sia con \const{Q\_GETQUOTA} per
+ottenere i valori correnti dei limiti e dell'occupazione delle risorse, che
+con \const{Q\_SETQUOTA} per effettuare modifiche ai limiti. Come si può notare
+ci sono alcuni campi (in sostanza \val{dqb\_curspace}, \val{dqb\_curinodes},
+\val{dqb\_btime}, \val{dqb\_itime}) che hanno senso solo in lettura, in quanto
+riportano uno stato non modificabile da \func{quotactl} come l'uso corrente di
+spazio disco ed \itindex{inode} \textit{inode}, o il tempo che resta nel caso
+si sia superato un \textit{soft limit}.
-\begin{table}[htb]
+Inoltre in caso di modifica di un limite si può voler operare solo su una
+delle risorse (blocchi o \itindex{inode} \textit{inode}),\footnote{non è
+ possibile modificare soltanto uno dei limiti (\textit{hard} o \textit{soft})
+ occorre sempre rispecificarli entrambi.} per questo la struttura prevede un
+campo apposito, \val{dqb\_valid}, il cui scopo è quello di indicare quali sono
+gli altri campi che devono essere considerati validi. Questo campo è una
+maschera binaria che deve essere espressa nei termini di OR aritmetico delle
+apposite costanti di tab.~\ref{tab:quotactl_qif_const}, dove si è riportato il
+significato di ciascuna di esse ed i campi a cui fanno riferimento.
+
+\begin{table}[!htb]
\centering
\footnotesize
\begin{tabular}{|l|p{10cm}|}
\label{tab:quotactl_qif_const}
\end{table}
+In lettura con \const{Q\_SETQUOTA} eventuali valori presenti in \struct{dqblk}
+vengono comunque ignorati, al momento la funzione sovrascrive tutti i campi
+che restituisce e li marca come validi in \val{dqb\_valid}. Si possono invece
+usare \const{QIF\_BLIMITS} o \const{QIF\_ILIMITS} per richiedere di impostare
+solo la rispettiva tipologia di limiti con \const{Q\_SETQUOTA}. Si tenga
+presente che il sistema delle quote richiede che l'occupazione di spazio disco
+sia indicata in termini di blocchi e non di byte, dato che la dimensione dei
+blocchi dipende da come si è creato il filesystem potrà essere necessario
+effettuare qualche conversione per avere un valore in byte.\footnote{in genere
+ viene usato un default di 1024 byte per blocco, ma quando si hanno file di
+ dimensioni medie maggiori può convenire usare valori più alti per ottenere
+ prestazioni migliori in conseguenza di un minore frazionamento dei dati e di
+ indici più corti.}
+
+Come accennato realizzazione delle quote disco ha visto diverse revisioni, con
+modifiche sia del formato delle stesse che dei nomi dei file utilizzate. Per
+questo alcune operazioni di gestione (in particolare \const{Q\_QUOTAON} e
+\const{Q\_GETFMT}) e possono fare riferimento a queste versioni, che vengono
+identificate tramite le costanti di tab.~\ref{tab:quotactl_id_format}.
-Inoltre in caso di modifica di un limite si può voler operare solo su una
-delle risorse (blocchi o \itindex{inode} \textit{inode});\footnote{non è
- possibile modificare soltanto uno dei limiti (\textit{hard} o \textit{soft})
- occorre sempre rispecificarli entrambi.} per questo la struttura prevede un
-campo apposito, \val{dqb\_valid}, il cui scopo è quello di indicare quali sono
-gli altri campi che devono essere considerati validi. Questo campo è una
-maschera binaria che deve essere espressa nei termini di OR aritmetico delle
-apposite costanti di tab.~\ref{tab:quotactl_qif_const}, dove si è riportato il
-significato di ciascuna di esse ed i campi a cui fanno riferimento.
+\begin{table}[htb]
+ \centering
+ \footnotesize
+ \begin{tabular}{|l|p{10cm}|}
+ \hline
+ \textbf{Identificatore} & \textbf{Descrizione} \\
+ \hline
+ \hline
+ \const{QFMT\_VFS\_OLD}& Il vecchio (ed obsoleto) formato delle quote.\\
+ \const{QFMT\_VFS\_V0} & La versione 0 usata dal VFS di Linux, supporta
+ \ids{UID} e \ids{GID} a 32 bit e limiti fino a
+ $2^{42}$ byte e $2^{32}$ file.\\
+ \const{QFMT\_VFS\_V1} & La versione 1 usata dal VFS di Linux, supporta
+ \ids{UID} e \ids{GID} a 32 bit e limiti fino a
+ $2^{64}$ byte e $2^{64}$ file.\\
+ \hline
+ \end{tabular}
+ \caption{Valori di identificazione del formato delle quote.}
+ \label{tab:quotactl_id_format}
+\end{table}
-In lettura con \const{Q\_SETQUOTA} eventuali valori presenti in \struct{dqblk}
-vengono comunque ignorati, al momento la funzione sovrascrive tutti i campi e
-li marca come validi in \val{dqb\_valid}. Si possono invece usare
-\const{QIF\_BLIMITS} o \const{QIF\_ILIMITS} per richiedere di impostare solo
-la rispettiva tipologia di limiti con \const{Q\_SETQUOTA}. Si tenga presente
-che il sistema delle quote richiede che l'occupazione di spazio disco sia
-indicata in termini di blocchi e non di byte; dato che questo dipende da come
-si è creato il filesystem potrà essere necessario effettuare qualche
-controllo.\footnote{in genere viene usato un default di 1024 byte per blocco,
- ma quando si hanno file di dimensioni medie maggiori può convenire usare
- valori più alti per ottenere prestazioni migliori in conseguenza di un
- minore frazionamento dei dati e di indici più corti.}
-
-Altre due operazioni che necessitano di un approfondimento sono
-\const{Q\_GETINFO} e \const{Q\_SETINFO}, che sostanzialmente consentono di
-ottenere i dati relativi alle impostazioni delle altre proprietà delle quote,
-che si riducono poi alla durata del \textit{grace time} per i due tipi di
-limiti. In questo caso queste si proprietà generali sono identiche per tutti
-gli utenti, per cui viene usata una operazione distinta dalle
-precedenti. Anche in questo caso le due operazioni richiedono l'uso di una
-apposita struttura \struct{dqinfo}, la cui definizione è riportata in
-fig.~\ref{fig:dqinfo_struct}.
+
+
+Altre due operazioni che necessitano di ulteriori spiegazioni sono
+\const{Q\_GETINFO} e \const{Q\_SETINFO}, che consentono di ottenere i dati
+relativi alle impostazioni delle altre proprietà delle quote, che al momento
+sono solo la durata del \textit{grace time} per i due tipi di limiti. Queste
+sono due proprietà generali identiche per tutti gli utenti (e i gruppi), per
+cui viene usata una operazione distinta dalle precedenti. Anche in questo caso
+le due operazioni richiedono l'uso di una apposita struttura \struct{dqinfo},
+la cui definizione è riportata in fig.~\ref{fig:dqinfo_struct}.
\begin{figure}[!htb]
\footnotesize \centering
- \begin{minipage}[c]{\textwidth}
+ \begin{minipage}[c]{0.8\textwidth}
\includestruct{listati/dqinfo.h}
\end{minipage}
\normalsize
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
+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à.}
+misure potranno essere comunque rimosse.\footnote{nei casi elencati nella
+ precedente nota si potrà sempre rimontare il sistema in lettura-scrittura, o
+ togliere l'attributo 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
+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.
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}''.
+molto più fine nella distribuzione degli stessi che evitasse la situazione
+originaria di ``\textsl{tutto o nulla}''.
\itindbeg{file~capabilities}
Per i kernel fino al 2.6.25, o se non si attiva il supporto per le
\textit{file capabilities}, il \textit{capabilities bounding set} è un
parametro generale di sistema, il cui valore viene riportato nel file
-\sysctlfile{kernel/cap-bound}. Il suo valore iniziale è definito in
-sede di compilazione del kernel, e da sempre ha previsto come default la
-presenza di tutte le \textit{capabilities} eccetto \const{CAP\_SETPCAP}. In
-questa situazione solo il primo processo eseguito nel sistema (quello con
+\sysctlfile{kernel/cap-bound}. Il suo valore iniziale è definito in sede di
+compilazione del kernel, e da sempre ha previsto come default la presenza di
+tutte le \textit{capabilities} eccetto \const{CAP\_SETPCAP}. In questa
+situazione solo il primo processo eseguito nel sistema (quello con
\textsl{pid} 1, di norma \texttt{/sbin/init}) ha la possibilità di
modificarlo; ogni processo eseguito successivamente, se dotato dei privilegi
di amministratore, è in grado soltanto di rimuovere una delle
\textit{capabilities} già presenti dell'insieme.\footnote{per essere precisi
- occorreva la capacità \const{CAP\_SYS\_MODULE}.}
+ occorre la capacità \const{CAP\_SYS\_MODULE}.}
In questo caso l'effetto complessivo del \textit{capabilities bounding set} è
che solo le capacità in esso presenti possono essere trasmesse ad un altro
\texttt{file\_*} quelli del file eseguito e con \texttt{bound\_set} il
\textit{capabilities bounding set}, dopo l'invocazione di \func{exec} il
processo otterrà dei nuovi insiemi di capacità \texttt{new\_*} secondo la
-formula (espressa in pseudo-codice C) di fig.~\ref{fig:cap_across_exec}; si
-noti come in particolare il \textit{capabilities bounding set} non viene
-comunque modificato e resta lo stesso sia attraverso una \func{fork} che
-attraverso una \func{exec}.
+formula espressa dal seguente pseudo-codice C:
+
+\includecodesnip{listati/cap-results.c}
+
+% \begin{figure}[!htbp]
+% \footnotesize \centering
+% \begin{minipage}[c]{12cm}
+% \includecodesnip{listati/cap-results.c}
+% \end{minipage}
+% \caption{Espressione della modifica delle \textit{capabilities} attraverso
+% una \func{exec}.}
+% \label{fig:cap_across_exec}
+% \end{figure}
+
+\noindent e si noti come in particolare il \textit{capabilities bounding set}
+non venga comunque modificato e resti lo stesso sia attraverso una \func{fork}
+che attraverso una \func{exec}.
-\begin{figure}[!htbp]
- \footnotesize \centering
- \begin{minipage}[c]{12cm}
- \includecodesnip{listati/cap-results.c}
- \end{minipage}
- \caption{Espressione della modifica delle \textit{capabilities} attraverso
- una \func{exec}.}
- \label{fig:cap_across_exec}
-\end{figure}
\itindend{capabilities~bounding~set}
\const{SECURE\_NO\_SETUID\_FIXUP} e con \const{SECURE\_NOROOT\_LOCKED} per
\const{SECURE\_NOROOT}.
-Per l'impostazione di questi flag sono stata predisposte due specifiche
+Per l'impostazione di questi flag sono state predisposte due specifiche
operazioni di \func{prctl} (vedi sez.~\ref{sec:process_prctl}),
\const{PR\_GET\_SECUREBITS}, che consente di ottenerne il valore, e
\const{PR\_SET\_SECUREBITS}, che consente di modificarne il valore; per
\begin{table}[!h!btp]
\centering
\footnotesize
- \begin{tabular}{|l|p{10.5cm}|}
+ \begin{tabular}{|l|p{10cm}|}
\hline
\textbf{Capacità}&\textbf{Descrizione}\\
\hline
%
% POSIX-draft defined capabilities.
%
- \const{CAP\_AUDIT\_CONTROL}& La capacità di abilitare e disabilitare il
+ \const{CAP\_AUDIT\_CONTROL}& Abilitare e disabilitare il
controllo dell'auditing (dal kernel 2.6.11).\\
- \const{CAP\_AUDIT\_WRITE}&La capacità di scrivere dati nel giornale di
+ \const{CAP\_AUDIT\_WRITE}&Scrivere dati nel giornale di
auditing del kernel (dal kernel 2.6.11).\\
% TODO verificare questa roba dell'auditing
- \const{CAP\_CHOWN} & La capacità di cambiare proprietario e gruppo
+ \const{CAP\_CHOWN} & 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
+ \const{CAP\_DAC\_OVERRIDE}& 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
+ file, (vedi sez.~\ref{sec:file_access_control}).\\
+ \const{CAP\_DAC\_READ\_SEARCH}& 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\_FOWNER} & 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
+ \const{CAP\_FSETID} & 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
quando questo è relativo ad un gruppo cui non si
appartiene (vedi
sez.~\ref{sec:file_perm_management}).\\
- \const{CAP\_KILL} & La capacità di mandare segnali a qualunque
+ \const{CAP\_KILL} & Mandare segnali a qualunque
processo (vedi sez.~\ref{sec:sig_kill_raise}).\\
- \const{CAP\_SETFCAP} & La capacità di impostare le
+ \const{CAP\_SETFCAP} & Impostare le
\textit{capabilities} di un file (dal kernel
2.6.24).\\
- \const{CAP\_SETGID} & La capacità di manipolare i group ID dei
+ \const{CAP\_SETGID} & 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
+ \const{CAP\_SETUID} & 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
% Linux specific capabilities
%
\hline
- \const{CAP\_IPC\_LOCK} & La capacità di effettuare il \textit{memory
+ \const{CAP\_IPC\_LOCK} & 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
+ \const{CAP\_IPC\_OWNER} & 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}
+ \const{CAP\_LEASE} & Creare dei \textit{file lease}
\itindex{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
+ \const{CAP\_LINUX\_IMMUTABLE}& Impostare sui file gli
attributi \textit{immutable} e
\itindex{append~mode} \textit{append-only} (vedi
sez.~\ref{sec:file_perm_overview}) se
supportati.\\
- \const{CAP\_MKNOD} & La capacità di creare
+ \const{CAP\_MKNOD} & 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
+ \const{CAP\_NET\_ADMIN} & Eseguire alcune operazioni
privilegiate sulla rete.\\
- \const{CAP\_NET\_BIND\_SERVICE}& La capacità di porsi in ascolto
+ \const{CAP\_NET\_BIND\_SERVICE}& 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
+ \const{CAP\_NET\_BROADCAST}& 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
+ \const{CAP\_NET\_RAW} & Usare socket \texttt{RAW} e
\texttt{PACKET} (vedi sez.~\ref{sec:sock_type}).\\
- \const{CAP\_SETPCAP} & La capacità di modifiche privilegiate alle
+ \const{CAP\_SETPCAP} & Effettuare modifiche privilegiate alle
\textit{capabilities}.\\
- \const{CAP\_SYS\_ADMIN} & La capacità di eseguire una serie di compiti
+ \const{CAP\_SYS\_ADMIN} & Eseguire una serie di compiti
amministrativi.\\
- \const{CAP\_SYS\_BOOT} & La capacità di fare eseguire un riavvio del
+ \const{CAP\_SYS\_BOOT} & Eseguire un riavvio del
sistema (vedi sez.~\ref{sec:sys_reboot}).\\
- \const{CAP\_SYS\_CHROOT}& La capacità di eseguire la funzione
+ \const{CAP\_SYS\_CHROOT}& Eseguire la funzione
\func{chroot} (vedi sez.~\ref{sec:file_chroot}).\\
- \const{CAP\_MAC\_ADMIN} & La capacità amministrare il \textit{Mandatory
+ \const{CAP\_MAC\_ADMIN} & Amministrare il \textit{Mandatory
Access Control} di Smack (dal kernel 2.6.25).\\
- \const{CAP\_MAC\_OVERRIDE}& La capacità evitare il \textit{Mandatory
+ \const{CAP\_MAC\_OVERRIDE}& Evitare il \textit{Mandatory
Access Control} di Smack (dal kernel 2.6.25).\\
- \const{CAP\_SYS\_MODULE}& La capacità di caricare e rimuovere moduli del
+ \const{CAP\_SYS\_MODULE}& Caricare e rimuovere moduli del
kernel.\\
- \const{CAP\_SYS\_NICE} & La capacità di modificare le varie priorità dei
+ \const{CAP\_SYS\_NICE} & Modificare le varie priorità dei
processi (vedi sez.~\ref{sec:proc_priority}).\\
- \const{CAP\_SYS\_PACCT} & La capacità di usare le funzioni di
+ \const{CAP\_SYS\_PACCT} & 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:process_ptrace}).\\
- \const{CAP\_SYS\_RAWIO} & La capacità di operare sulle porte
+ \const{CAP\_SYS\_RAWIO} & Operare sulle porte
di I/O con \func{ioperm} e \func{iopl} (vedi
sez.~\ref{sec:process_io_port}).\\
- \const{CAP\_SYS\_RESOURCE}& La capacità di superare le varie limitazioni
+ \const{CAP\_SYS\_RESOURCE}& Superare le varie limitazioni
sulle risorse.\\
- \const{CAP\_SYS\_TIME} & La capacità di modificare il tempo di sistema
+ \const{CAP\_SYS\_TIME} & Modificare il tempo di sistema
(vedi sez.~\ref{sec:sys_time}).\\
- \const{CAP\_SYS\_TTY\_CONFIG}& La capacità di simulare un \textit{hangup}
+ \const{CAP\_SYS\_TTY\_CONFIG}&Simulare un \textit{hangup}
della console, con la funzione
\func{vhangup}.\\
- \const{CAP\_SYSLOG} & La capacità di gestire il buffer dei messaggi
+ \const{CAP\_SYSLOG} & Gestire il buffer dei messaggi
del kernel, (vedi sez.~\ref{sec:sess_daemon}),
introdotta dal kernel 2.6.38 come capacità
separata da \const{CAP\_SYS\_ADMIN}.\\
- \const{CAP\_WAKE\_ALARM}& La capacità di usare i timer di tipo
+ \const{CAP\_WAKE\_ALARM}& Usare i timer di tipo
\const{CLOCK\_BOOTTIME\_ALARM} e
\const{CLOCK\_REALTIME\_ALARM}, vedi
sez.~\ref{sec:sig_timer_adv} (dal kernel 3.0).\\
\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).}
+% \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).}
Prima di dettagliare il significato della capacità più generiche, conviene
stato completamente cambiato con l'introduzione delle \textit{file
capabilities} nel kernel 2.6.24. In precedenza questa capacità era quella
che permetteva al processo che la possedeva di impostare o rimuovere le
-\textit{capabilities} che fossero presenti nel \textit{permitted set} del
-chiamante di un qualunque altro processo. In realtà questo non è mai stato
-l'uso inteso nelle bozze dallo standard POSIX, ed inoltre, come si è già
-accennato, dato che questa capacità è assente nel \textit{capabilities
- bounding set} usato di default, essa non è neanche mai stata realmente
-disponibile.
+\textit{capabilities} presenti nel suo \textit{permitted set} su un qualunque
+altro processo. In realtà questo non è mai stato l'uso inteso nelle bozze
+dallo standard POSIX, ed inoltre, come si è già accennato, dato che questa
+capacità è sempre stata assente (a meno di specifiche ricompilazioni del
+kernel) nel \textit{capabilities bounding set} usato di default, essa non è
+neanche mai stata realmente disponibile.
Con l'introduzione \itindex{file~capabilities} \textit{file capabilities} e
il cambiamento del significato del \textit{capabilities bounding set} la
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 dei file (vedi sez.~\ref{sec:file_ioctl}) e delle
-ACL (vedi sez.~\ref{sec:file_xattr} e \ref{sec:file_ACL}), poter ignorare lo
+impostazioni degli attributi dei file 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.
+sez.~\ref{sec:file_open_close} e sez.~\ref{sec:file_fcntl_ioctl}) 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
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:
+tre insiemi illustrati in precedenza. Queste due funzioni di sistema sono
+\funcd{capget} e \funcd{capset} e costituiscono l'interfaccia di gestione
+basso livello; i loro rispettivi prototipi sono:
\begin{funcproto}{
\fhead{sys/capability.h}
\fdesc{Imposta le \textit{capabilities}.}
}
-{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
+{Le funzioni ritornano $0$ in caso di successo e $-1$ per un errore, nel qual
caso \var{errno} assumerà uno dei 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}.
+ \item[\errcode{EFAULT}] si è indicato un puntatore sbagliato o nullo
+ per \param{hdrp} o \param{datap} (quest'ultimo può essere nullo solo se si
+ usa \func{capget} per ottenere la versione delle \textit{capabilities}
+ usata dal kernel).
+ \item[\errcode{EINVAL}] si è specificato un valore non valido per uno dei
+ campi di \param{hdrp}, in particolare una versione non valida della
+ versione delle \textit{capabilities}.
+ \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}.
+ \item[\errcode{ESRCH}] si è fatto riferimento ad un processo inesistente.
\end{errlist}
- ed inoltre \errval{EFAULT} ed \errval{EINVAL}
- nel loro significato generico.}
+}
\end{funcproto}
-
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 un certo periodo di tempo era anche
presente.\footnote{e non è chiaro neanche quanto sia mai stato davvero
necessario.}
-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{viene però
- garantito che le vecchie funzioni continuino a funzionare.} Pertanto se si
-vogliono scrivere programmi portabili che possano essere eseguiti senza
-modifiche o adeguamenti su qualunque versione del kernel è opportuno
-utilizzare le interfacce di alto livello che vedremo più avanti.
-
\begin{figure}[!htb]
\footnotesize
\centering
- \begin{minipage}[c]{\textwidth}
+ \begin{minipage}[c]{0.8\textwidth}
\includestruct{listati/cap_user_header_t.h}
\end{minipage}
\normalsize
\label{fig:cap_kernel_struct}
\end{figure}
+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{viene però
+ garantito che le vecchie funzioni continuino a funzionare.} Pertanto se si
+vogliono scrivere programmi portabili che possano essere eseguiti senza
+modifiche o adeguamenti su qualunque versione del kernel è opportuno
+utilizzare le interfacce di alto livello che vedremo più avanti.
+
La struttura a cui deve puntare l'argomento \param{hdrp} serve ad indicare,
-tramite il campo \var{pid}, il PID del processo del quale si vogliono leggere
-o modificare le \textit{capabilities}. Con \func{capset} questo, se si usano
-le \itindex{file~capabilities} \textit{file capabilities}, può essere solo 0 o
-PID del processo chiamante, che sono equivalenti. Il campo \var{version} deve
-essere impostato al valore della versione delle stesse usata dal kernel
-(quello indicato da una delle costanti
+tramite il campo \var{pid}, il \ids{PID} del processo del quale si vogliono
+leggere o modificare le \textit{capabilities}. Con \func{capset} questo, se si
+usano le \itindex{file~capabilities} \textit{file capabilities}, può essere
+solo 0 o il \ids{PID} del processo chiamante, che sono equivalenti. Non
+tratteremo, essendo comunque di uso irrilevante, il caso in cui, in mancanza
+di tale supporto, la funzione può essere usata per modificare le
+\textit{capabilities} di altri processi, per il quale si rimanda, se
+interessati, alla lettura della pagina di manuale.
+
+Il campo \var{version} deve essere impostato al valore della versione delle
+stesse usata dal kernel (quello indicato da una delle costanti
\texttt{\_LINUX\_CAPABILITY\_VERSION\_n} 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
-versione due è comunque deprecata e non deve essere usata (il kernel stamperà
-un avviso). I valori delle \textit{capabilities} devono essere passati come
-maschere binarie;\footnote{e si tenga presente che i valori di
+versione due è comunque deprecata e non deve essere usata, ed il kernel
+stamperà un avviso se lo si fa.
+
+I valori delle \textit{capabilities} devono essere passati come maschere
+binarie;\footnote{e si tenga presente che i valori di
tab.~\ref{tab:proc_capabilities} non possono essere combinati direttamente,
indicando il numero progressivo del bit associato alla relativa capacità.}
con l'introduzione delle \textit{capabilities} a 64 bit inoltre il
dello standard POSIX.1e, non fanno parte della \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 un
-\index{tipo!opaco} 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}.
+programma le utilizza si dovrà indicare esplicitamente al compilatore l'uso
+della suddetta libreria attraverso l'opzione \texttt{-lcap}.
+
+\itindbeg{capability~state}
+
+Le funzioni dell'interfaccia alle \textit{capabilities} definite nelle bozze
+dello standard POSIX.1e prevedono l'uso di un \index{tipo!opaco} 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 fanno 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 i \textit{capability state}, che presentano notevoli affinità,
+essendo parte di bozze dello stesso standard, con quelle già viste per le ACL.
La prima funzione dell'interfaccia è quella che permette di inizializzare un
\textit{capability state}, allocando al contempo la memoria necessaria per i
\fdesc{Crea ed inizializza un \textit{capability state}.}
}
-{La funzione ritorna un valore non nullo in caso di successo e\val{NULL} per
- un errore, nel qual caso \var{errno} potrà assumere solo il valore
- \errval{ENOMEM}.
-}
+{La funzione ritorna un \textit{capability state} in caso di successo e
+ \val{NULL} per un errore, nel qual caso \var{errno} potrà assumere solo il
+ valore \errval{ENOMEM}. }
\end{funcproto}
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 \val{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 è:
+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{funcproto}{
\fhead{sys/capability.h}
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 motivo 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}.
+sarà 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 sarà un dato di tipo
+\texttt{char *}. Per questo motivo l'argomento \param{obj\_d} è dichiarato
+come \texttt{void *}, per evitare la necessità di eseguire un \textit{cast},
+ma dovrà comunque corrispondere ad un puntatore ottenuto tramite le altre
+funzioni della libreria, altrimenti la funzione fallirà con un errore di
+\errval{EINVAL}.
Infine si può creare una copia di un \textit{capability state} ottenuto in
precedenza tramite la funzione \funcd{cap\_dup}, il cui prototipo è:
\fdesc{Duplica un \textit{capability state} restituendone una copia.}
}
-{La funzione ritorna un valore non nullo in caso di successo e \val{NULL} per
- un errore, nel qual caso \var{errno} assumerà valori \errval{ENOMEM} o
- \errval{EINVAL} nel loro significato generico.}
+{La funzione ritorna un \textit{capability state} in caso di successo e
+ \val{NULL} per un errore, nel qual caso \var{errno} assumerà i valori
+ \errval{ENOMEM} o \errval{EINVAL} nel loro significato generico.}
\end{funcproto}
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. }
+potranno essere modificati in maniera completamente indipendente, ed alla fine
+delle operazioni si dovrà disallocare anche la copia, oltre all'originale.
Una seconda classe di funzioni di servizio previste dall'interfaccia sono
quelle per la gestione dei dati contenuti all'interno di un \textit{capability
restituendo uno stato \textsl{vuoto}, analogo a quello che si ottiene nella
creazione con \func{cap\_init}.
+Una variante di \func{cap\_clear} è \funcd{cap\_clear\_flag} che cancella da
+un \textit{capability state} tutte le \textit{capabilities} di un certo
+insieme fra quelli elencati a pag.~\pageref{sec:capabilities_set}, il suo
+prototipo è:
+
+\begin{funcproto}{
+\fhead{sys/capability.h}
+\fdecl{int cap\_clear\_flag(cap\_t cap\_p, cap\_flag\_t flag)}
+\fdesc{Cancella delle \textit{capabilities} da un \textit{capability state}.}
+}
+
+{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
+ caso \var{errno} potrà assumere solo il valore \errval{EINVAL}.
+}
+\end{funcproto}
+
+La funzione richiede che si indichi quale degli insiemi si intente cancellare
+da \param{cap\_p} con l'argomento \param{flag}. Questo deve essere specificato
+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
+ \headfile{sys/capability.h}.} uno dei valori illustrati in
+tab.~\ref{tab:cap_set_identifier}.
+
\begin{table}[htb]
\centering
\footnotesize
\label{tab:cap_set_identifier}
\end{table}
-Una variante di \func{cap\_clear} è \funcd{cap\_clear\_flag} che cancella da
-un \textit{capability state} tutte le \textit{capabilities} di un certo
-insieme fra quelli di pag.~\pageref{sec:capabilities_set}, il suo prototipo
-è:
-
-\begin{funcproto}{
-\fhead{sys/capability.h}
-\fdecl{int cap\_clear\_flag(cap\_t cap\_p, cap\_flag\_t flag)}
-\fdesc{ncella dal \textit{capability state} \param{cap\_p} tutte le
- \textit{capabilities} dell'insieme \param{flag}.}
-}
-
-{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
- caso \var{errno} potrà assumere solo il valore \errval{EINVAL}.
-}
-\end{funcproto}
-
-La funzione richiede che si indichi quale degli insiemi si intente cancellare
-con l'argomento \param{flag}. Questo deve essere specificato 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 \headfile{sys/capability.h}.} uno dei valori
-illustrati in tab.~\ref{tab:cap_set_identifier}.
-
Si possono inoltre confrontare in maniera diretta due diversi
\textit{capability state} con la funzione \funcd{cap\_compare}; il suo
prototipo è:
\end{funcbox}
}
-La macro che richiede si passi nell'argomento \texttt{value} il risultato
+La macro richiede che si passi nell'argomento \texttt{value} il risultato
della funzione \func{cap\_compare} e in \texttt{flag} l'indicazione (coi
valori di tab.~\ref{tab:cap_set_identifier}) dell'insieme che si intende
controllare; restituirà un valore diverso da zero se le differenze rilevate da
\begin{funcproto}{
\fhead{sys/capability.h}
-\fdecl{int cap\_get\_flag(cap\_t cap\_p, cap\_value\_t cap, cap\_flag\_t
- flag, cap\_flag\_value\_t *value\_p)}
+\fdecl{int cap\_get\_flag(cap\_t cap\_p, cap\_value\_t cap, cap\_flag\_t
+flag,\\
+\phantom{int cap\_get\_flag(}cap\_flag\_value\_t *value\_p)}
\fdesc{Legge il valore di una \textit{capability}.}
\fdecl{int cap\_set\_flag(cap\_t cap\_p, cap\_flag\_t flag, int ncap,
- cap\_value\_t *caps, cap\_flag\_value\_t value)}
+ cap\_value\_t *caps, \\
+\phantom{int cap\_set\_flag(}cap\_flag\_value\_t value)}
\fdesc{Imposta il valore di una \textit{capability}.}
}
-{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
+{Le funzioni ritornano $0$ in caso di successo e $-1$ per un errore, nel qual
caso \var{errno} potrà assumere solo il valore \errval{EINVAL}.
}
\end{funcproto}
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 si intende operare, sempre con i valori di
-tab.~\ref{tab:cap_set_identifier}.
-
-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} può indicare una sola capacità.\footnote{in
+tab.~\ref{tab:cap_set_identifier}. 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} può indicare una sola capacità.\footnote{in
\headfile{sys/capability.h} il tipo \type{cap\_value\_t} è definito come
\ctyp{int}, ma i valori validi sono soltanto quelli di
tab.~\ref{tab:proc_capabilities}.}
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} lo restituisce nella variabile puntata
+\param{flag} e lo restituisce come \itindex{value~result~argument}
+\textit{value result argument} nella variabile puntata
dall'argomento \param{value\_p}. Questa deve essere di tipo
\type{cap\_flag\_value\_t} ed assumerà uno dei valori di
tab.~\ref{tab:cap_value_type}. La funzione consente pertanto di leggere solo
allo stesso valore. 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) per le capacità elencate in \param{caps} viene
+(cancellazione o attivazione) per le capacità elencate in \param{caps} viene
indicato dall'argomento \param{value} sempre con i valori di
tab.~\ref{tab:cap_value_type}.
\begin{funcproto}{
\fhead{sys/capability.h}
-\fdecl{char * cap\_to\_text(cap\_t caps, ssize\_t * length\_p)}
+\fdecl{char *cap\_to\_text(cap\_t caps, ssize\_t *length\_p)}
\fdesc{Genera una visualizzazione testuale delle \textit{capabilities}.}
}
La funzione ritorna l'indirizzo di una stringa contente la descrizione
testuale del contenuto del \textit{capability 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
+restituisce come \itindex{value~result~argument} \textit{value result
+ argument} 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}.
-La rappresentazione testuale, che viene usata anche di programmi di gestione a
+La rappresentazione testuale, che viene usata anche dai programmi di gestione a
riga di comando, prevede che lo stato venga rappresentato con una stringa di
testo composta da una serie di proposizioni separate da spazi, ciascuna delle
quali specifica una operazione da eseguire per creare lo stato finale. Nella
scrivere la lista completa. Gli insiemi sono identificati dalle tre lettere
iniziali: ``\texttt{p}'' per il \textit{permitted}, ``\texttt{i}'' per
l'\textit{inheritable} ed ``\texttt{e}'' per l'\textit{effective} che devono
-essere sempre minuscole e se ne può indicare più di uno.
+essere sempre minuscole, e se ne può indicare più di uno.
Gli operatori possibili sono solo tre: ``\texttt{+}'' che aggiunge le capacità
elencate agli insiemi indicati, ``\texttt{-}'' che le toglie e ``\texttt{=}''
accennato tradizionalmente \const{CAP\_SETPCAP} è sempre stata rimossa da
detto processo.
-Viceversa per passare ottenere un \textit{capability state} dalla sua
-rappresentazione testuale si può usare \funcd{cap\_from\_text}, il cui
-prototipo è:
+Viceversa per ottenere un \textit{capability state} dalla sua rappresentazione
+testuale si può usare la funzione \funcd{cap\_from\_text}, il cui prototipo è:
\begin{funcproto}{
\fhead{sys/capability.h}
\fdesc{Crea un \textit{capability state} dalla sua rappresentazione testuale.}
}
-{La funzione ritorna un puntatore valid in caso di successo e \val{NULL} per
- un errore, nel qual caso \var{errno} assumerà i valori \errval{EINVAL} o
- \errval{ENOMEM} nel loro significato generico.}
+{La funzione ritorna un \textit{capability state} in caso di successo e
+ \val{NULL} per un errore, nel qual caso \var{errno} assumerà i valori
+ \errval{EINVAL} o \errval{ENOMEM} nel loro significato generico.}
\end{funcproto}
\begin{funcproto}{
\fhead{sys/capability.h}
-\fdecl{char * cap\_to\_name(cap\_value\_t cap)}
+\fdecl{char *cap\_to\_name(cap\_value\_t cap)}
+\fdesc{Converte il valore numerico di una \textit{capabilities} alla sua
+ rappresentazione testuale.}
\fdecl{int cap\_from\_name(const char *name, cap\_value\_t *cap\_p)}
-\fdesc{Convertono le \textit{capabilities} dalle costanti alla rappresentazione
- testuale e viceversa.}
+\fdesc{Converte la rappresentazione testuale di una \textit{capabilities} al
+ suo valore numerico.}
}
{La funzione \func{cap\_to\_name} ritorna un puntatore ad una stringa in caso
di successo e \val{NULL} per un errore, mentre \func{cap\_to\_name} ritorna
- $0$ in caso di successo e $-1$ nel qual caso di errore, per entrambe
- \var{errno}può assumere i valori \errval{EINVAL} o \errval{ENOMEM}.
+ $0$ in caso di successo e $-1$ per un errore, per entrambe in caso di errore
+ \var{errno} assumerà i valori \errval{EINVAL} o \errval{ENOMEM} nel loro
+ significato generico.
}
\end{funcproto}
La prima funzione restituisce la stringa (allocata automaticamente e che dovrà
essere liberata con \func{cap\_free}) che corrisponde al valore della
capacità \param{cap}, mentre la seconda restituisce nella variabile puntata
-da \param{cap\_p} il valore della capacità rappresentata dalla
+da \param{cap\_p}, come \itindex{value~result~argument} \textit{value result
+ argument}, il valore della capacità rappresentata dalla
stringa \param{name}.
Fin quei abbiamo trattato solo le funzioni di servizio relative alla
\fdesc{Legge le \textit{capabilities} del processo corrente.}
}
-{La funzione ritorna un valore diverso da \val{NULL} in caso di successo e
+{La funzione ritorna un \textit{capability state} in caso di successo e
\val{NULL} per un errore, nel qual caso \var{errno} assumerà i valori
\errval{EINVAL}, \errval{EPERM} o \errval{ENOMEM} nel loro significato
generico.}
non sarà più utilizzato.
Se invece si vogliono leggere le \textit{capabilities} di un processo
-specifico occorre usare la funzione \funcd{capgetp}, il cui
+specifico occorre usare la funzione \funcd{cap\_get\_pid}, 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
\begin{funcproto}{
\fhead{sys/capability.h}
-\fdecl{int capgetp(pid\_t pid, cap\_t cap\_d)}
+\fdecl{cap\_t cap\_get\_pid(pid\_t pid)}
\fdesc{Legge le \textit{capabilities} di un processo.}
}
-{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
- caso \var{errno} assumerà i valori \errval{EINVAL}, \errval{EPERM} o
- \errval{ENOMEM} nel loro significato generico.}
+{La funzione ritorna un \textit{capability state} in caso di successo e
+ \val{NULL} per un errore, nel qual caso \var{errno} assumerà i valori
+ \errval{ESRCH} o \errval{ENOMEM} nel loro significato generico. }
\end{funcproto}
-%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{capability
- 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}
+con l'argomento \param{pid}, e restituisce il risultato tramite il puntatore
+ad un \textit{capability state} contenente tutti i dati che provvede ad
+allocare autonomamente e che al solito deve essere disallocato con
+\func{cap\_free}. 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{Command}
+$ cat /proc/1/status
+\end{Command}
+\begin{Terminal}
...
CapInh: 0000000000000000
CapPrm: 00000000fffffeff
CapEff: 00000000fffffeff
...
-\end{Verbatim}
+\end{Terminal}
+%$
-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 è:
+\itindend{capability~state}
+
+Infine per impostare le \textit{capabilities} del processo corrente (nella
+bozza dello standard POSIX.1e 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{funcproto}{
\fhead{sys/capability.h}
}
{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
- caso \var{errno} assumerà i valori \errval{EINVAL}, \errval{EPERM} o
- \errval{ENOMEM} nel loro significato generico.}
+ caso \var{errno} assumerà i valori:
+ \begin{errlist}
+ \item[\errcode{EPERM}] si è cercato di attivare una capacità non permessa.
+ \end{errlist} ed inoltre \errval{EINVAL} nel suo significato generico.}
\end{funcproto}
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).
+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).
+
+Oltre a queste funzioni su Linux sono presenti due ulteriori funzioni,
+\funcm{capgetp} e \funcm{capsetp}, che svolgono un compito analogo. Queste
+funzioni risalgono alla implementazione iniziale delle \textit{capabilities}
+ed in particolare \funcm{capsetp} consentirebbe anche, come possibile in quel
+caso, di cambiare le capacità di un altro processo. Le due funzioni oggi sono
+deprecate e pertanto eviteremo di trattarle, per chi fosse interessato si
+rimanda alla lettura della loro 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
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.
+processo qualunque il cui \ids{PID} viene passato come parametro dell'opzione.
\begin{figure}[!htbp]
\footnotesize \centering
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
+che si è tralasciata) al valore del \ids{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
+(\texttt{\small 1--6}) si utilizza (\texttt{\small 2}) \func{cap\_get\_proc}
+per ottenere lo stato delle capacità del processo, nel secondo (\texttt{\small
+ 7--13}) si usa invece \func{cap\_get\_pid} (\texttt{\small 8}) per leggere
+il valore delle capacità del processo indicato.
+
+Il passo successivo è utilizzare (\texttt{\small 15}) \func{cap\_to\_text} per
+tradurre in una stringa lo stato, e poi (\texttt{\small 16}) stamparlo; infine
+(\texttt{\small 18--19}) si libera la memoria allocata dalle precedenti
funzioni con \func{cap\_free} per poi ritornare dal ciclo principale della
funzione.
\subsection{La gestione dei {chroot}}
\label{sec:file_chroot}
-% TODO introdurre nuova sezione sulle funzionalità di sicurezza avanzate, con
-% dentro chroot SELinux e AppArmor, Tomoyo, Smack, cgroup o che altro ???
+% TODO: valutare se introdurre una nuova sezione sulle funzionalità di
+% sicurezza avanzate, con dentro chroot SELinux e AppArmor, Tomoyo, Smack,
+% cgroup o altro
+
+% TODO: trattare la funzione setns e i namespace file descriptors (vedi
+% http://lwn.net/Articles/407495/) introdotti con il kernel 3.0
+
+% TODO: spostare chroot e le funzioni affini relative ai container da qualche
+% parte diversa se è il caso.
-% inserire setns (introdotta con il 3.0, vedi http://lwn.net/Articles/407495/)
-% e le funzionalità di isolamento dei container
Benché non abbia niente a che fare con permessi, utenti e gruppi, la funzione
\func{chroot} viene usata spesso per restringere le capacità di accesso di un
programma ad una sezione limitata del filesystem, per cui ne parleremo in
questa sezione.
-% TODO riferimenti ai bind mount, link simbolici ecc.
-
Come accennato in sez.~\ref{sec:proc_fork} ogni processo oltre ad una
\index{directory~di~lavoro} directory di lavoro, ha anche una directory
\textsl{radice}\footnote{entrambe sono contenute in due campi (rispettivamente
\var{pwd} e \var{root}) di \kstruct{fs\_struct}; vedi
fig.~\ref{fig:proc_task_struct}.} che, pur essendo di norma corrispondente
-alla radice dell'albero di file e directory come visto dal kernel (ed
-illustrato in sez.~\ref{sec:file_pathname}), ha per il processo il significato
-specifico di directory rispetto alla quale vengono risolti i
+alla radice dell'albero dei file dell'intero sistema, ha per il processo il
+significato specifico di directory rispetto alla quale vengono risolti i
\itindsub{pathname}{assoluto}\textit{pathname} assoluti.\footnote{cioè quando
un processo chiede la risoluzione di un \textit{pathname}, il kernel usa
sempre questa directory come punto di partenza.} Il fatto che questo valore
sia specificato per ogni processo apre allora la possibilità di modificare le
-modalità di risoluzione dei \textit{pathname} assoluti da parte di un processo
-cambiando questa directory, così come si fa coi
-\itindsub{pathname}{relativo}\textit{pathname} relativi cambiando la
+modalità di risoluzione dei \itindsub{pathname}{assoluto} \textit{pathname}
+assoluti da parte di un processo cambiando questa directory, così come si fa
+coi \itindsub{pathname}{relativo} \textit{pathname} relativi cambiando la
\index{directory~di~lavoro} directory di lavoro.
-Normalmente la directory radice di un processo coincide anche con la radice
-del filesystem usata dal kernel, e dato che il suo valore viene ereditato dal
-padre da ogni processo figlio, in generale i processi risolvono i
-\itindsub{pathname}{assoluto} \textit{pathname} assoluti a partire sempre
-dalla stessa directory, che corrisponde alla radice del sistema.
+Normalmente la directory radice di un processo coincide con la radice generica
+dell'albero dei file, che è la directory che viene montata direttamente dal
+kernel all'avvio secondo quanto illustrato in sez.~\ref{sec:file_pathname}.
+Questo avviene perché, come visto in sez.~\ref{cha:process_handling} la
+directory radice di un processo viene ereditata dal padre attraverso una
+\func{fork} e mantenuta attraverso una \func{exec}, e siccome tutti i processi
+derivano da \cmd{init}, che ha come radice quella montata dal kernel, questa
+verrà mantenuta.
In certe situazioni però è utile poter impedire che un processo possa accedere
-a tutto il filesystem; per far questo si può cambiare la sua directory radice
-con la funzione \funcd{chroot}, il cui prototipo è:
+a tutto l'albero dei file iniziale; per far questo si può cambiare la sua
+directory radice con la funzione di sistema \funcd{chroot}, il cui prototipo
+è:
\begin{funcproto}{
\fhead{unistd.h}
{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
caso \var{errno} assumerà uno dei valori:
\begin{errlist}
- \item[\errcode{EPERM}] l'\ids{UID} effettivo del processo non è zero.
+ \item[\errcode{EPERM}] non si hanno i privilegi di amministratore.
\end{errlist}
- ed inoltre errval{EFAULT}, \errval{ENAMETOOLONG}, \errval{ENOENT},
+ ed inoltre \errval{EFAULT}, \errval{ENAMETOOLONG}, \errval{ENOENT},
\errval{ENOMEM}, \errval{ENOTDIR}, \errval{EACCES}, \errval{ELOOP};
\errval{EROFS} e \errval{EIO} nel loro significato generico.}
\end{funcproto}
-La funzione la directory radice del processo a quella specificata da
+La funzione imposta la directory radice del processo a quella specificata da
\param{path} (che ovviamente deve esistere) ed ogni
\itindsub{pathname}{assoluto} \textit{pathname} assoluto usato dalle funzioni
chiamate nel processo sarà risolto a partire da essa, rendendo impossibile
-accedere alla parte di albero sovrastante. Si ha così quella che viene
+accedere alla parte di albero sovrastante. Si ha così quella che viene
chiamata una \textit{chroot jail}, in quanto il processo non può più accedere
a file al di fuori della sezione di albero in cui è stato
\textsl{imprigionato}.
-Solo un processo con i privilegi di amministratore può usare questa funzione,
-e la nuova radice, per quanto detto in sez.~\ref{sec:proc_fork}, sarà ereditata
-da tutti i suoi processi figli. Si tenga presente però che la funzione non
-cambia la directory di lavoro, che potrebbe restare fuori dalla \textit{chroot
- jail}.
-
-Questo è il motivo per cui la funzione è efficace solo se dopo averla eseguita
-si cedono i privilegi di root. Infatti se per un qualche motivo il processo
-resta con \index{directory~di~lavoro} la directory di lavoro fuori dalla
-\textit{chroot jail}, potrà comunque accedere a tutto il resto del filesystem
-usando \itindsub{pathname}{relativo}\textit{pathname} relativi, i quali,
-partendo dalla directory di lavoro che è fuori della \textit{chroot jail},
-potranno (con l'uso di ``\texttt{..}'') risalire fino alla radice effettiva
-del filesystem.
-
-Ma se ad un processo restano i privilegi di amministratore esso potrà comunque
-portare la sua \index{directory~di~lavoro} directory di lavoro fuori dalla
-\textit{chroot jail} in cui si trova. Basta infatti creare una nuova
-\textit{chroot jail} con l'uso di \func{chroot} su una qualunque directory
-contenuta nell'attuale directory di lavoro. Per questo motivo l'uso di questa
-funzione non ha molto senso quando un processo necessita dei privilegi di root
+Solo un processo con i privilegi di amministratore può usare questa
+funzione,\footnote{più precisamente se possiede la \itindex{capabilities}
+ capacità \const{CAP\_SYS\_CHROOT}.} e la nuova radice, per quanto detto in
+sez.~\ref{sec:proc_fork}, sarà ereditata da tutti i suoi processi figli. Si
+tenga presente però che la funzione non cambia la directory di lavoro del
+processo, che potrebbe restare fuori dalla \textit{chroot jail}.
+
+Questo è il motivo per cui la funzione è efficace nel restringere un processo
+ad un ramo di albero solo se dopo averla eseguita si cedono i privilegi di
+amministratore. Infatti se per un qualunque motivo il processo resta con la
+sua \index{directory~di~lavoro} directory di lavoro al di fuori dalla
+\textit{chroot jail}, potrà accedere a tutto il resto del filesystem usando
+\itindsub{pathname}{relativo} dei \textit{pathname} relativi, dato che in tal
+caso è possibile, grazie all'uso di ``\texttt{..}'', risalire all'indietro
+fino alla radice effettiva dell'albero dei file.
+
+Potrebbe sembrare che per risolvere il problema sia sufficiente ricordarsi di
+eseguire preventivamente anche una \func{chdir} sulla directory su cui si
+andrà ad eseguire \func{chroot}, così da assicurarsi che le directory di
+lavoro sia all'interno della \textit{chroot jail}. Ma se ad un processo
+restano i privilegi di amministratore esso potrà comunque portare la sua
+\index{directory~di~lavoro} directory di lavoro fuori dalla \textit{chroot
+ jail} in cui si trova. Basterà infatti eseguire di nuovo \func{chroot} su
+una qualunque directory contenuta nell'attuale directory di lavoro perché
+quest'ultima risulti al di fuori della nuova \textit{chroot jail}. Per questo
+motivo l'uso di questa funzione non ha molto senso quando un processo di cui
+si vuole limitare l'accesso necessita comunque dei privilegi di amministratore
per le sue normali operazioni.
-Un caso tipico di uso di \func{chroot} è quello di un server FTP anonimo, in
-questo caso infatti si vuole che il server veda solo i file che deve
-trasferire, per cui in genere si esegue una \func{chroot} sulla directory che
-contiene i file. Si tenga presente però che in questo caso occorrerà
-replicare all'interno della \textit{chroot jail} tutti i file (in genere
-programmi e librerie) di cui il server potrebbe avere bisogno.
-
+Nonostante queste limitazioni la funzione risulta utile qualora la si possa
+applicare correttamente cedendo completamente i privilegi di amministratore
+una volta eseguita. Ed esempio caso tipico di uso di \func{chroot} è quello
+di un server FTP anonimo in si vuole che il server veda solo i file che deve
+trasferire. In tal caso si esegue una \func{chroot} sulla directory che
+contiene i file, che il server dovrà in grado di leggere come utente
+ordinario, e poi si cedono tutti i privilegi di amministratore. Si tenga
+presente però che in casi come questo occorrerà fornire all'interno della
+\textit{chroot jail} un accesso anche a tutti i file (in genere programmi e
+librerie) di cui il server potrebbe avere bisogno.
-% TODO: trattare la funzione setns e i namespace file descriptors (vedi
-% http://lwn.net/Articles/407495/) introdotti con il kernel 3.0
-
-% TODO: spostare chroot e le funzioni affini relative ai container da qualche
-% parte diversa se è il caso.
-
% LocalWords: sez like filesystem unlink MacOS Windows VMS inode kernel unistd
% LocalWords: int const char oldpath newpath errno EXDEV EPERM st Smack SysV
% LocalWords: EEXIST EMLINK EACCES ENAMETOOLONG ENOTDIR EFAULT ENOMEM EROFS ls
% LocalWords: lazy encfs sshfs setfsent getfsent getfsfile getfsspec endfsent
% LocalWords: setmntent getmntent addmntent endmntent hasmntopt such offsetof
% LocalWords: member scan attack EOVERFLOW BITS blkcnt rdev FDCWD functions
+% LocalWords: faccessat grpid lacl AppArmor capsetp mygetfacl
%%% Local Variables:
%%% mode: latex
projects / gapil.git / blobdiff