X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=filedir.tex;h=df4576e1238d4687733bae7efbb2b5466a1414d2;hp=b0e42ac6c1b1a910504a180b7a0cf182babe0d55;hb=6760429dc70f868716393c4413c5450b0649869b;hpb=4eaaee43e4e0df09fae1ba66466ee77ff78db517 diff --git a/filedir.tex b/filedir.tex index b0e42ac..df4576e 100644 --- a/filedir.tex +++ b/filedir.tex @@ -1,6 +1,6 @@ %% filedir.tex %% -%% Copyright (C) 2000-2013 Simone Piccardi. Permission is granted to +%% Copyright (C) 2000-2015 Simone Piccardi. Permission is granted to %% copy, distribute and/or modify this document under the terms of the GNU Free %% Documentation License, Version 1.1 or any later version published by the %% Free Software Foundation; with the Invariant Sections being "Un preambolo", @@ -1095,8 +1095,8 @@ prototipo è: \errval{ENOENT}, \errval{ENOMEM} nel loro significato generico. } \end{funcproto} -\footnotetext{più precisamente la \itindex{capabilities} capacità - \const{CAP\_SYS\_ADMIN}, vedi sez.~\ref{sec:proc_capabilities}.} +\footnotetext{più precisamente la capacità \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 @@ -2025,9 +2025,9 @@ directory. Si tenga presente che comunque la funzione opera associando il \textit{directory stream} ad un opportuno file descriptor sottostante, sul quale vengono compiute le operazioni. Questo viene sempre aperto impostando il -flag di \itindex{close-on-exec} \textit{close-on-exec} (si ricordi quanto -detto in sez.~\ref{sec:proc_exec}), così da evitare che resti aperto in caso -di esecuzione di un altro programma. +flag di \textit{close-on-exec} (si ricordi quanto detto in +sez.~\ref{sec:proc_exec}), così da evitare che resti aperto in caso di +esecuzione di un altro programma. Nel caso in cui sia necessario conoscere il \textit{file descriptor} associato ad un \textit{directory stream} si può usare la funzione @@ -2098,9 +2098,8 @@ funzioni che operano sul \textit{directory stream} e non dovrà essere più utilizzato all'interno del proprio programma. In particolare dovrà essere chiuso attraverso il \textit{directory stream} con \func{closedir} e non direttamente. Si tenga presente inoltre che \func{fdopendir} non modifica lo -stato di un eventuale flag di \itindex{close-on-exec} \textit{close-on-exec}, -che pertanto dovrà essere impostato esplicitamente in fase di apertura del -file descriptor. +stato di un eventuale flag di \textit{close-on-exec}, che pertanto dovrà +essere impostato esplicitamente in fase di apertura del file descriptor. Una volta che si sia aperto un \textit{directory stream} la lettura del contenuto della directory viene effettuata attraverso la funzione @@ -2442,10 +2441,10 @@ la stampa della sintassi, anch'essa omessa, ma il codice completo può essere trovato coi sorgenti allegati alla guida nel file \file{myls.c}. In sostanza tutto quello che fa il programma, dopo aver controllato -(\texttt{\small 12--15}) di avere almeno un argomento, che indicherà la +(\texttt{\small 12-15}) di avere almeno un argomento, che indicherà la directory da esaminare, è chiamare (\texttt{\small 16}) la funzione \myfunc{dir\_scan} per eseguire la scansione, usando la funzione \code{do\_ls} -(\texttt{\small 22--29}) per fare tutto il lavoro. +(\texttt{\small 22-29}) per fare tutto il lavoro. Quest'ultima si limita (\texttt{\small 26}) a chiamare \func{stat} sul file indicato dalla directory entry passata come argomento (il cui nome è appunto @@ -2472,15 +2471,15 @@ Tutto il grosso del lavoro è svolto dalla funzione \myfunc{dir\_scan}, riportata in fig.~\ref{fig:file_dirscan}. La funzione è volutamente generica e permette di eseguire una funzione, passata come secondo argomento, su tutte le voci di una directory. La funzione inizia con l'aprire (\texttt{\small - 18--22}) uno \textit{stream} sulla directory passata come primo argomento, + 18-22}) uno \textit{stream} sulla directory passata come primo argomento, stampando un messaggio in caso di errore. -Il passo successivo (\texttt{\small 23--24}) è cambiare +Il passo successivo (\texttt{\small 23-24}) è cambiare \index{directory~di~lavoro} directory di lavoro (vedi sez.~\ref{sec:file_work_dir}), usando in sequenza le funzioni \func{dirfd} e \func{fchdir} (in realtà si sarebbe potuto usare direttamente \func{chdir} su \var{dirname}), in modo che durante il successivo ciclo (\texttt{\small - 26--30}) sulle singole voci dello \textit{stream} ci si trovi all'interno + 26-30}) sulle singole voci dello \textit{stream} ci si trovi all'interno della directory.\footnote{questo è essenziale al funzionamento della funzione \code{do\_ls}, e ad ogni funzione che debba usare il campo \var{d\_name}, in quanto i nomi dei file memorizzati all'interno di una struttura @@ -2715,16 +2714,15 @@ Qualora si sia specificato in \param{mode} un file di dispositivo (vale a dire o \const{S\_IFBLK} o \const{S\_IFCHR}), il valore di \param{dev} dovrà essere usato per indicare a quale dispositivo si fa riferimento, altrimenti il suo valore verrà ignorato. Solo l'amministratore può creare un file di -dispositivo usando questa funzione (il processo deve avere la -\itindex{capabilities} \textit{capability} \const{CAP\_MKNOD}), ma in -Linux\footnote{questo è un comportamento specifico di Linux, la funzione non è - prevista dallo standard POSIX.1 originale, mentre è presente in SVr4 e - 4.4BSD, ma esistono differenze nei comportamenti e nei codici di errore, - tanto che questa è stata introdotta in POSIX.1-2001 con una nota che la - definisce portabile solo quando viene usata per creare delle fifo, ma - comunque deprecata essendo utilizzabile a tale scopo la specifica - \func{mkfifo}.} l'uso per la creazione di un file ordinario, di una fifo o -di un socket è consentito anche agli utenti normali. +dispositivo usando questa funzione (il processo deve avere la capacità +\const{CAP\_MKNOD}), ma in Linux\footnote{questo è un comportamento specifico + di Linux, la funzione non è prevista dallo standard POSIX.1 originale, + mentre è presente in SVr4 e 4.4BSD, ma esistono differenze nei comportamenti + e nei codici di errore, tanto che questa è stata introdotta in POSIX.1-2001 + con una nota che la definisce portabile solo quando viene usata per creare + delle fifo, ma comunque deprecata essendo utilizzabile a tale scopo la + specifica \func{mkfifo}.} l'uso per la creazione di un file ordinario, di +una fifo o di un socket è consentito anche agli utenti normali. I nuovi \itindex{inode} \textit{inode} creati con \func{mknod} apparterranno al proprietario e al gruppo del processo (usando \ids{UID} e \ids{GID} del @@ -3643,7 +3641,7 @@ tempo corrente ed è sufficiente avere accesso in scrittura al file o essere 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}, vedi + essere precisi la 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. @@ -3874,15 +3872,14 @@ campo \var{st\_gid} della omonima struttura \struct{stat}. Il controllo di accesso ai file segue un modello abbastanza semplice che prevede tre permessi fondamentali strutturati su tre livelli di accesso. -Esistono varie estensioni a questo modello,\footnote{come le - \itindex{Access~Control~List~(ACL)} \textit{Access Control List} che sono - 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 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: +Esistono varie estensioni a questo modello,\footnote{come le \textit{Access + Control List} che sono 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 \textit{Mandatory Access Control} + di \textit{SELinux} 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}). @@ -4109,7 +4106,7 @@ 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}, vedi + 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}. @@ -4456,10 +4453,10 @@ misura di sicurezza, volta a scongiurare l'abuso dei \itindex{suid~bit} bit \acr{suid} e \acr{sgid}; essa consiste nel cancellare automaticamente questi bit dai permessi di un file qualora un processo che non appartenga all'amministratore\footnote{per la precisione un processo che non dispone - della \itindex{capabilities} capacità \const{CAP\_FSETID}, vedi - sez.~\ref{sec:proc_capabilities}.} effettui una scrittura. In questo modo -anche se un utente malizioso scopre un file \acr{suid} su cui può scrivere, -un'eventuale modifica comporterà la perdita di questo privilegio. + della capacità \const{CAP\_FSETID}, vedi sez.~\ref{sec:proc_capabilities}.} +effettui una scrittura. In questo modo anche se un utente malizioso scopre un +file \acr{suid} su cui può scrivere, un'eventuale modifica comporterà la +perdita di questo privilegio. Le funzioni \func{chmod} e \func{fchmod} ci permettono di modificare i permessi di un file, resta però il problema di quali sono i permessi assegnati @@ -4595,14 +4592,14 @@ prototipi sono: Le funzioni cambiano utente e gruppo di appartenenza di un file ai valori specificati dalle variabili \param{owner} e \param{group}. Con Linux solo -l'amministratore\footnote{o in generale un processo con la - \itindex{capabilities} capacità \const{CAP\_CHOWN}, vedi - sez.~\ref{sec:proc_capabilities}.} può cambiare il proprietario di un file; -in questo viene seguita la semantica usata da BSD che non consente agli utenti -di assegnare i loro file ad altri utenti evitando eventuali aggiramenti delle -quote. L'amministratore può cambiare sempre il gruppo di un file, il -proprietario può cambiare il gruppo solo dei file che gli appartengono e solo -se il nuovo gruppo è il suo gruppo primario o uno dei gruppi di cui fa parte. +l'amministratore\footnote{o in generale un processo con la capacità + \const{CAP\_CHOWN}, vedi sez.~\ref{sec:proc_capabilities}.} può cambiare il +proprietario di un file; in questo viene seguita la semantica usata da BSD che +non consente agli utenti di assegnare i loro file ad altri utenti evitando +eventuali aggiramenti delle quote. L'amministratore può cambiare sempre il +gruppo di un file, il proprietario può cambiare il gruppo solo dei file che +gli appartengono e solo se il nuovo gruppo è il suo gruppo primario o uno dei +gruppi di cui fa parte. La funzione \func{chown} segue i collegamenti simbolici, per operare direttamente su un collegamento simbolico si deve usare la funzione @@ -4753,12 +4750,11 @@ Per risolvere questo problema alcuni sistemi unix-like (e fra questi anche Linux) hanno introdotto un meccanismo generico, detto \textit{Extended Attributes} che consente di associare delle informazioni ulteriori ai singoli file.\footnote{essi ad esempio vengono usati per le ACL, che - tratteremo in sez.~\ref{sec:file_ACL} e le \itindex{file~capabilities} - \textit{file capabilities}, che vedremo in - sez.~\ref{sec:proc_capabilities}.} Gli \textsl{attributi estesi} non sono -altro che delle coppie nome/valore che sono associate permanentemente ad un -oggetto sul filesystem, analoghi di quello che sono le variabili di ambiente -(vedi sez.~\ref{sec:proc_environ}) per un processo. + tratteremo in sez.~\ref{sec:file_ACL} e le \textit{file capabilities}, che + vedremo in sez.~\ref{sec:proc_capabilities}.} Gli \textsl{attributi estesi} +non sono altro che delle coppie nome/valore che sono associate permanentemente +ad un oggetto sul filesystem, analoghi di quello che sono le variabili di +ambiente (vedi sez.~\ref{sec:proc_environ}) per un processo. Altri sistemi (come Solaris, MacOS e Windows) hanno adottato un meccanismo diverso in cui ad un file sono associati diversi flussi di dati, su cui @@ -4815,15 +4811,13 @@ classi di attributi riportate in tab.~\ref{tab:extended_attribute_class}. \hline \texttt{security}&Gli \textit{extended security attributes}: vengono utilizzati dalle estensioni di sicurezza del kernel (i - \itindex{Linux~Security~Modules} \textit{Linux - Security Modules}), per le realizzazione di meccanismi - evoluti di controllo di accesso come \index{SELinux} - SELinux o le \textit{capabilities} dei file di - sez.~\ref{sec:proc_capabilities}.\\ + \textit{Linux Security Modules}), per le realizzazione + di meccanismi evoluti di controllo di accesso come + \textit{SELinux} o le \textit{capabilities} dei + file di sez.~\ref{sec:proc_capabilities}.\\ \texttt{system} & Gli \textit{extended security attributes}: sono usati dal kernel per memorizzare dati di sistema associati ai - file come le \itindex{Access~Control~List~(ACL)} ACL (vedi - sez.~\ref{sec:file_ACL}) o le \itindex{capabilities} + file come le ACL (vedi sez.~\ref{sec:file_ACL}) o le \textit{capabilities} (vedi sez.~\ref{sec:proc_capabilities}).\\ \texttt{trusted}& I \textit{trusted extended attributes}: vengono @@ -4844,43 +4838,40 @@ classi di attributi riportate in tab.~\ref{tab:extended_attribute_class}. Dato che uno degli usi degli \textit{Extended Attributes} è di impiegarli per -realizzare delle estensioni (come le \itindex{Access~Control~List~(ACL)} ACL, -\index{SELinux} SELinux, ecc.) al tradizionale meccanismo dei controlli di -accesso di Unix, l'accesso ai loro valori viene regolato in maniera diversa a -seconda sia della loro classe che di quali, fra le estensioni che li -utilizzano, sono poste in uso. In particolare, per ciascuna delle classi -riportate in tab.~\ref{tab:extended_attribute_class}, si hanno i seguenti -casi: +realizzare delle estensioni (come le ACL, \textit{SELinux}, ecc.) al +tradizionale meccanismo dei controlli di accesso di Unix, l'accesso ai loro +valori viene regolato in maniera diversa a seconda sia della loro classe che +di quali, fra le estensioni che li utilizzano, sono poste in uso. In +particolare, per ciascuna delle classi riportate in +tab.~\ref{tab:extended_attribute_class}, si hanno i seguenti casi: \begin{basedescript}{\desclabelwidth{1.7cm}\desclabelstyle{\nextlinelabel}} \item[\texttt{security}] L'accesso agli \textit{extended security attributes} dipende dalle politiche di sicurezza stabilite da loro stessi tramite - l'utilizzo di un sistema di controllo basato sui - \itindex{Linux~Security~Modules} \textit{Linux Security Modules} (ad esempio - \index{SELinux} SELinux). Pertanto l'accesso in lettura o scrittura dipende - dalle politiche di sicurezza implementate all'interno dal modulo di - sicurezza che si sta utilizzando al momento (ciascuno avrà le sue). Se non è - stato caricato nessun modulo di sicurezza l'accesso in lettura sarà - consentito a tutti i processi, mentre quello in scrittura solo ai processi - con privilegi amministrativi dotati della \itindex{capabilities} - \textit{capability} \const{CAP\_SYS\_ADMIN}. + l'utilizzo di un sistema di controllo basato sui \textit{Linux Security + Modules} (ad esempio \textit{SELinux}). Pertanto l'accesso in lettura o + scrittura dipende dalle politiche di sicurezza implementate all'interno dal + modulo di sicurezza che si sta utilizzando al momento (ciascuno avrà le + sue). Se non è stato caricato nessun modulo di sicurezza l'accesso in + lettura sarà consentito a tutti i processi, mentre quello in scrittura solo + ai processi con privilegi amministrativi dotati della capacità + \const{CAP\_SYS\_ADMIN}. \item[\texttt{system}] Anche l'accesso agli \textit{extended system attributes} dipende dalle politiche di accesso che il kernel realizza anche utilizzando gli stessi valori in essi contenuti. Ad esempio nel caso - delle \itindex{Access~Control~List~(ACL)} ACL l'accesso è consentito in - lettura ai processi che hanno la capacità di eseguire una ricerca sul file - (cioè hanno il permesso di lettura sulla directory che contiene il file) ed - in scrittura al proprietario del file o ai processi dotati della - \textit{capability} \itindex{capabilities} + delle ACL (vedi sez.~\ref{sec:file_ACL}) l'accesso è consentito in lettura + ai processi che hanno la capacità di eseguire una ricerca sul file (cioè + hanno il permesso di lettura sulla directory che contiene il file) ed in + scrittura al proprietario del file o ai processi dotati della capacità \const{CAP\_FOWNER}.\footnote{vale a dire una politica di accesso analoga a quella impiegata per gli ordinari permessi dei file.} \item[\texttt{trusted}] L'accesso ai \textit{trusted extended attributes}, sia per la lettura che per la scrittura, è consentito soltanto ai processi con - privilegi amministrativi dotati della \itindex{capabilities} - \textit{capability} \const{CAP\_SYS\_ADMIN}. In questo modo si possono - utilizzare questi attributi per realizzare in user space dei meccanismi di - controllo che accedono ad informazioni non disponibili ai processi ordinari. + privilegi amministrativi dotati della capacità \const{CAP\_SYS\_ADMIN}. In + questo modo si possono utilizzare questi attributi per realizzare in user + space dei meccanismi di controllo che accedono ad informazioni non + disponibili ai processi ordinari. \item[\texttt{user}] L'accesso agli \textit{extended user attributes} è regolato dai normali permessi dei file: occorre avere il permesso di lettura @@ -4919,8 +4910,7 @@ casi: per evitare eventuali abusi, se una directory ha lo \itindex{sticky~bit} \textit{sticky bit} attivo sarà consentito scrivere i suoi \textit{extended user attributes} soltanto se si è proprietari della stessa, o si hanno i - privilegi amministrativi della capacità \itindex{capabilities} - \const{CAP\_FOWNER}. + privilegi amministrativi della capacità \const{CAP\_FOWNER}. \end{basedescript} Le funzioni per la gestione degli attributi estesi, come altre funzioni di @@ -5187,7 +5177,7 @@ può impostare una ACL aggiuntiva, detta ``\textit{Default ACL}'', che serve ad indicare quale dovrà essere la ACL assegnata di default nella creazione di un file all'interno della directory stessa. Come avviene per i permessi le ACL possono essere impostate solo del proprietario del file, o da un processo con -la capacità \itindex{capabilities} \const{CAP\_FOWNER}. +la capacità \const{CAP\_FOWNER}. \begin{table}[htb] \centering @@ -5305,9 +5295,9 @@ quali viene stabilito se il processo ha il diritto di accesso sono i seguenti: \begin{enumerate} \item Se l'\ids{UID} del processo è nullo (se cioè si è l'amministratore) l'accesso è sempre garantito senza nessun controllo.\footnote{più - precisamente se si devono avere le \itindex{capabilities} capacità - \const{CAP\_DAC\_OVERRIDE} per i file e \const{CAP\_DAC\_READ\_SEARCH} per - le directory, vedi sez.~\ref{sec:proc_capabilities}.} + precisamente se si devono avere le capacità \const{CAP\_DAC\_OVERRIDE} per + i file e \const{CAP\_DAC\_READ\_SEARCH} per le directory, vedi + sez.~\ref{sec:proc_capabilities}.} \item Se l'\ids{UID} del processo corrisponde al proprietario del file allora: \begin{itemize*} \item se la voce \const{ACL\_USER\_OBJ} contiene il permesso richiesto, @@ -5931,17 +5921,17 @@ ACL di un file, passato come argomento. 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 +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 +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 +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 +aver liberato (\texttt{\small 33-34}) le risorse allocate automaticamente, si conclude l'esecuzione. @@ -6159,7 +6149,7 @@ 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} + tab.~\ref{tab:quotactl_commands} richiedono la capacità \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. @@ -6371,11 +6361,11 @@ quote.\footnote{questi vengono passati come argomenti dalle funzioni mappate con \macro{QCMD} al comando \const{Q\_GETQUOTA} per ottenere i dati. La funzione viene eseguita all'interno di un condizionale (\texttt{\small - 5--16}) che in caso di successo provvede a costruire (\texttt{\small 6--12}) + 5-16}) che in caso di successo provvede a costruire (\texttt{\small 6-12}) opportunamente una risposta restituendo tramite la opportuna funzione di interfaccia un oggetto Python contenente i dati della struttura \struct{dqblk} relativi a uso corrente e limiti sia per i blocchi che per gli \itindex{inode} -\textit{inode}. In caso di errore (\texttt{\small 13--15}) si usa un'altra +\textit{inode}. In caso di errore (\texttt{\small 13-15}) si usa un'altra funzione dell'interfaccia per passare il valore di \var{errno} come eccezione. \begin{figure}[!htbp] @@ -6392,16 +6382,16 @@ riportata in fig.~\ref{fig:set_block_quota}, che prende gli stessi argomenti della precedente, con lo stesso significato, a cui si aggiungono i valori per il \textit{soft limit} e l'\textit{hard limit}. In questo caso occorrerà, prima di chiamare \func{quotactl}, inizializzare opportunamente -(\texttt{\small 5--7}) i campi della struttura \struct{dqblk} che si vogliono +(\texttt{\small 5-7}) i campi della struttura \struct{dqblk} che si vogliono utilizzare (quelli relativi ai limiti sui blocchi) e specificare gli stessi con \const{QIF\_BLIMITS} in \var{dq.dqb\_valid}. Fatto questo la chiamata a \func{quotactl}, stavolta con il comando \const{Q\_SETQUOTA}, viene eseguita come in precedenza all'interno di un -condizionale (\texttt{\small 9--14}). In questo caso non essendovi da +condizionale (\texttt{\small 9-14}). In questo caso non essendovi da restituire nessun dato in caso di successo si usa (\texttt{\small 10}) una apposita funzione di uscita, mentre si restituisce come prima una eccezione -con il valore di \var{errno} in caso di errore (\texttt{\small 12--13}). +con il valore di \var{errno} in caso di errore (\texttt{\small 12-13}). \subsection{La gestione delle \textit{capabilities}} @@ -6413,13 +6403,12 @@ Come accennato in sez.~\ref{sec:proc_access_id} l'architettura classica della gestione dei privilegi in un sistema unix-like ha il sostanziale problema di fornire all'amministratore dei poteri troppo ampi. Questo comporta che anche quando si siano predisposte delle misure di protezione per in essere in grado -di difendersi dagli effetti di una eventuale compromissione del -sistema,\footnote{come montare un filesystem in sola lettura per impedirne - modifiche, o marcare un file come immutabile.} una volta che questa sia -stata effettuata e si siano ottenuti i privilegi di amministratore, queste -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à.} +di difendersi dagli effetti di una eventuale compromissione del sistema (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 misure potranno essere comunque +rimosse (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 @@ -6427,9 +6416,22 @@ separazione: per i processi normali essi sono posti in atto, mentre per i processi con i privilegi di amministratore essi non vengono neppure eseguiti. Per questo motivo non era previsto alcun modo per evitare che un processo con diritti di amministratore non potesse eseguire certe operazioni, o per cedere -definitivamente alcuni privilegi da un certo momento in poi. - -Per ovviare a tutto ciò, a partire dai kernel della serie 2.2, è stato +definitivamente alcuni privilegi da un certo momento in poi. + +Per risolvere questo problema sono possibili varie soluzioni ed ad esempio dai +kernel 2.5 è stata introdotta la struttura dei +\itindex{Linux~Security~Modules} \textit{Linux Security Modules} che han +permesso di aggiungere varie forme di \itindex{Mandatory~Access~Control~(DAC)} +\textit{Mandatory Access Control} (MAC), in cui si potessero parcellizzare e +controllare nei minimi dettagli tutti i privilegi e le modalità in cui questi +possono essere usati dai programmi e trasferiti agli utenti, con la creazione +di varie estensioni (come \textit{SELinux}, \textit{Smack}, \textit{Tomoyo}, +\textit{AppArmor}) che consentono di superare l'architettura tradizionale dei +permessi basati sul modello classico del controllo di accesso chiamato +\itindex{Discrectionary~Access~Control~(DAC)} \textit{Discrectionary Access + Control} (DAC). + +Ma già in precedenza, a partire dai kernel della serie 2.2, era stato introdotto un meccanismo, detto \textit{capabilities}, che consentisse di suddividere i vari privilegi tradizionalmente associati all'amministratore in un insieme di \textsl{capacità} distinte. L'idea era che queste capacità @@ -6440,18 +6442,17 @@ originaria di ``\textsl{tutto o nulla}''. \itindbeg{file~capabilities} -Il meccanismo completo delle \textit{capabilities}\footnote{l'implementazione - si rifà ad una bozza di quello che doveva diventare lo standard POSIX.1e, - poi abbandonato.} prevede inoltre la possibilità di associare le stesse ai -singoli file eseguibili, in modo da poter stabilire quali capacità possono -essere utilizzate quando viene messo in esecuzione uno specifico programma; ma -il supporto per questa funzionalità, chiamata \textit{file capabilities}, è -stato introdotto soltanto a partire dal kernel 2.6.24. Fino ad allora doveva -essere il programma stesso ad eseguire una riduzione esplicita delle sue -capacità, cosa che ha reso l'uso di questa funzionalità poco diffuso, vista la -presenza di meccanismi alternativi per ottenere limitazioni delle capacità -dell'amministratore a livello di sistema operativo, come \index{SELinux} -SELinux. +Il meccanismo completo delle \textit{capabilities} (l'implementazione si rifà +ad una bozza di quello che doveva diventare lo standard POSIX.1e, poi +abbandonato) prevede inoltre la possibilità di associare le stesse ai singoli +file eseguibili, in modo da poter stabilire quali capacità possono essere +utilizzate quando viene messo in esecuzione uno specifico programma; ma il +supporto per questa funzionalità, chiamata \textit{file capabilities}, è stato +introdotto soltanto a partire dal kernel 2.6.24. Fino ad allora doveva essere +il programma stesso ad eseguire una riduzione esplicita delle sue capacità, +cosa che ha reso l'uso di questa funzionalità poco diffuso, vista la presenza +di meccanismi alternativi per ottenere limitazioni delle capacità +dell'amministratore a livello di sistema operativo, come \textit{SELinux}. Con questo supporto e con le ulteriori modifiche introdotte con il kernel 2.6.25 il meccanismo delle \textit{capabilities} è stato totalmente @@ -6830,6 +6831,8 @@ opportuno dettagliare maggiormente. \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\_BLOCK\_SUSPEND}&Utilizzare funzionalità che possono bloccare + la sospensione del sistema (dal kernel 3.5).\\ \const{CAP\_CHOWN} & Cambiare proprietario e gruppo proprietario di un file (vedi sez.~\ref{sec:file_ownership_management}).\\ @@ -6855,9 +6858,8 @@ opportuno dettagliare maggiormente. sez.~\ref{sec:file_perm_management}).\\ \const{CAP\_KILL} & Mandare segnali a qualunque processo (vedi sez.~\ref{sec:sig_kill_raise}).\\ - \const{CAP\_SETFCAP} & Impostare le - \textit{capabilities} di un file (dal kernel - 2.6.24).\\ + \const{CAP\_SETFCAP} & Impostare le \textit{capabilities} di un file (dal kernel + 2.6.24).\\ \const{CAP\_SETGID} & Manipolare i group ID dei processi, sia il principale che i supplementari, (vedi sez.~\ref{sec:proc_setgroups}) che quelli @@ -6877,7 +6879,8 @@ opportuno dettagliare maggiormente. funzioni \func{mlock}, \func{mlockall}, \func{shmctl}, \func{mmap} (vedi sez.~\ref{sec:proc_mem_lock} e - sez.~\ref{sec:file_memory_map}). \\ + sez.~\ref{sec:file_memory_map}). \\ +% TODO verificare l'interazione con SHM_HUGETLB \const{CAP\_IPC\_OWNER} & Evitare il controllo dei permessi per le operazioni sugli oggetti di intercomunicazione fra processi (vedi @@ -6888,8 +6891,7 @@ opportuno dettagliare maggiormente. pur non essendo proprietari del file (dal kernel 2.4).\\ \const{CAP\_LINUX\_IMMUTABLE}& Impostare sui file gli attributi - \textit{immutable} e \itindex{append~mode} - \textit{append-only} (vedi + \textit{immutable} e \textit{append-only} (vedi sez.~\ref{sec:file_perm_overview}) se supportati.\\ \const{CAP\_MKNOD} & Creare \index{file!di~dispositivo} file di @@ -6912,9 +6914,11 @@ opportuno dettagliare maggiormente. \const{CAP\_SYS\_CHROOT}& Eseguire la funzione \func{chroot} (vedi sez.~\ref{sec:file_chroot}).\\ \const{CAP\_MAC\_ADMIN} & Amministrare il \textit{Mandatory - Access Control} di Smack (dal kernel 2.6.25).\\ - \const{CAP\_MAC\_OVERRIDE}& Evitare il \textit{Mandatory - Access Control} di Smack (dal kernel 2.6.25).\\ + Access Control} di \textit{Smack} (dal kernel + 2.6.25).\\ + \const{CAP\_MAC\_OVERRIDE}& Evitare il \textit{Mandatory + Access Control} di \textit{Smack} (dal kernel + 2.6.25).\\ \const{CAP\_SYS\_MODULE}& Caricare e rimuovere moduli del kernel.\\ \const{CAP\_SYS\_NICE} & Modificare le varie priorità dei processi (vedi sez.~\ref{sec:proc_priority}).\\ @@ -6947,10 +6951,6 @@ opportuno dettagliare maggiormente. \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).} - Prima di dettagliare il significato della capacità più generiche, conviene però dedicare un discorso a parte a \const{CAP\_SETPCAP}, il cui significato è @@ -6964,17 +6964,16 @@ 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 -possibilità di modificare le capacità di altri processi è stata completamente -rimossa, e \const{CAP\_SETPCAP} ha acquisito quello che avrebbe dovuto essere -il suo significato originario, e cioè la capacità del processo di poter -inserire nel suo \textit{inheritable set} qualunque capacità presente nel -\textit{bounding set}. Oltre a questo la disponibilità di \const{CAP\_SETPCAP} -consente ad un processo di eliminare una capacità dal proprio \textit{bounding - set} (con la conseguente impossibilità successiva di eseguire programmi con -quella capacità), o di impostare i \textit{securebits} delle -\textit{capabilities}. +Con l'introduzione \textit{file capabilities} e il cambiamento del significato +del \textit{capabilities bounding set} la possibilità di modificare le +capacità di altri processi è stata completamente rimossa, e +\const{CAP\_SETPCAP} ha acquisito quello che avrebbe dovuto essere il suo +significato originario, e cioè la capacità del processo di poter inserire nel +suo \textit{inheritable set} qualunque capacità presente nel \textit{bounding + set}. Oltre a questo la disponibilità di \const{CAP\_SETPCAP} consente ad un +processo di eliminare una capacità dal proprio \textit{bounding set} (con la +conseguente impossibilità successiva di eseguire programmi con quella +capacità), o di impostare i \textit{securebits} delle \textit{capabilities}. La prima fra le capacità ``\textsl{ampie}'' che occorre dettagliare maggiormente è \const{CAP\_FOWNER}, che rimuove le restrizioni poste ad un @@ -7108,12 +7107,11 @@ 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 \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. +usano le \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 @@ -7665,14 +7663,14 @@ 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 \ids{PID} del processo di cui si vuole leggere le \textit{capabilities} e nulla altrimenti. Nel primo caso -(\texttt{\small 1--6}) si utilizza (\texttt{\small 2}) \func{cap\_get\_proc} +(\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 + 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 +(\texttt{\small 18-19}) si libera la memoria allocata dalle precedenti funzioni con \func{cap\_free} per poi ritornare dal ciclo principale della funzione. @@ -7761,8 +7759,8 @@ 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,\footnote{più precisamente se possiede la \itindex{capabilities} - capacità \const{CAP\_SYS\_CHROOT}.} e la nuova radice, per quanto detto in +funzione,\footnote{più precisamente se possiede la 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}.