X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=filedir.tex;h=b3d4e92fc4b20aa3cef7141384ad5f09e9c9bc70;hp=461bcacb47675dc6acad30db75d0c61558eee390;hb=85590332c245e487cff2b566b2df286acc4289ee;hpb=4a64ffb309155737e851268a29e4217987a9c15e diff --git a/filedir.tex b/filedir.tex index 461bcac..b3d4e92 100644 --- a/filedir.tex +++ b/filedir.tex @@ -584,7 +584,7 @@ La funzione che permette la cancellazione di una directory è invece \begin{errlist} \item[\errcode{EPERM}] il filesystem non supporta la cancellazione di directory, oppure la directory che contiene \param{dirname} ha lo - \itindex{sticky~bit} \textit{sticky bit} impostato e l'user-ID effettivo + \itindex{sticky~bit} \textit{sticky bit} impostato e l'\acr{uid} effettivo del processo non corrisponde al proprietario della directory. \item[\errcode{EACCES}] non c'è il permesso di scrittura per la directory che contiene la directory che si vuole cancellare, o non c'è il permesso @@ -722,9 +722,9 @@ serie 2.4 alla serie 2.6 è stata aumentata a 32 bit la dimensione del tipo \type{dev\_t}, con delle dimensioni passate a 12 bit per il \itindex{major~number} \textit{major number} e 20 bit per il \itindex{minor~number} \textit{minor number}. La transizione però ha anche -comportato il passaggio di \type{dev\_t} a tipo opaco, e la necessità di -specificare il numero tramite delle opportune macro, così da non avere -problemi di compatibilità con eventuali ulteriori estensioni. +comportato il passaggio di \type{dev\_t} a \index{tipo!opaco} tipo opaco, e la +necessità di specificare il numero tramite delle opportune macro, così da non +avere problemi di compatibilità con eventuali ulteriori estensioni. Le macro sono definite nel file \file{sys/sysmacros.h}, che viene automaticamente incluso quando si include \file{sys/types.h}; si possono @@ -918,7 +918,7 @@ esaurite tutte le voci in essa presenti. \begin{figure}[!htb] \footnotesize \centering - \begin{minipage}[c]{15cm} + \begin{minipage}[c]{\textwidth} \includestruct{listati/dirent.c} \end{minipage} \normalsize @@ -1156,9 +1156,9 @@ estensione\footnote{le glibc, a partire dalla versione 2.1, effettuano anche ordina i nomi tenendo conto del numero di versione (cioè qualcosa per cui \texttt{file10} viene comunque dopo \texttt{file4}.) -\begin{figure}[!htb] +\begin{figure}[!htbp] \footnotesize \centering - \begin{minipage}[c]{15.6cm} + \begin{minipage}[c]{\codesamplewidth} \includecodesample{listati/my_ls.c} \end{minipage} \caption{Esempio di codice per eseguire la lista dei file contenuti in una @@ -1195,9 +1195,9 @@ voce presente questo è sufficiente a stampare la lista completa dei file e delle relative dimensioni. Si noti infine come si restituisca sempre 0 come valore di ritorno per indicare una esecuzione senza errori. -\begin{figure}[!htb] +\begin{figure}[!htbp] \footnotesize \centering - \begin{minipage}[c]{15.6cm} + \begin{minipage}[c]{\codesamplewidth} \includecodesample{listati/DirScan.c} \end{minipage} \caption{Codice della funzione di scansione di una directory contenuta nel @@ -1616,7 +1616,7 @@ sez.~\ref{sec:file_file_times}), o per il padding dei campi. \begin{figure}[!htb] \footnotesize \centering - \begin{minipage}[c]{15cm} + \begin{minipage}[c]{\textwidth} \includestruct{listati/stat.h} \end{minipage} \normalsize @@ -2016,7 +2016,7 @@ puntatore nullo verrà impostato il tempo corrente. \begin{figure}[!htb] \footnotesize \centering - \begin{minipage}[c]{15cm} + \begin{minipage}[c]{\textwidth} \includestruct{listati/utimbuf.h} \end{minipage} \normalsize @@ -2079,7 +2079,7 @@ puntatore nullo di nuovo verrà utilizzato il tempo corrente. \begin{figure}[!htb] \footnotesize \centering - \begin{minipage}[c]{15cm} + \begin{minipage}[c]{\textwidth} \includestruct{listati/timeval.h} \end{minipage} \normalsize @@ -2151,7 +2151,7 @@ definizione è riportata in fig.~\ref{fig:sys_timespec_struct}. \begin{figure}[!htb] \footnotesize \centering - \begin{minipage}[c]{15cm} + \begin{minipage}[c]{\textwidth} \includestruct{listati/timespec.h} \end{minipage} \normalsize @@ -2355,8 +2355,8 @@ veda sez.~\ref{sec:file_special_perm}). La procedura con cui il kernel stabilisce se un processo possiede un certo permesso (di lettura, scrittura o esecuzione) si basa sul confronto fra l'utente e il gruppo a cui il file appartiene (i valori di \var{st\_uid} e -\var{st\_gid} accennati in precedenza) e l'user-ID effettivo, il group-ID -effettivo e gli eventuali group-ID supplementari del processo.\footnote{in +\var{st\_gid} accennati in precedenza) e l'\acr{uid} effettivo, il \acr{gid} +effettivo e gli eventuali \acr{gid} supplementari del processo.\footnote{in realtà Linux, per quanto riguarda l'accesso ai file, utilizza gli identificatori del gruppo \textit{filesystem} (si ricordi quanto esposto in sez.~\ref{sec:proc_perms}), ma essendo questi del tutto equivalenti ai primi, @@ -2365,19 +2365,19 @@ effettivo e gli eventuali group-ID supplementari del processo.\footnote{in Per una spiegazione dettagliata degli identificatori associati ai processi si veda sez.~\ref{sec:proc_perms}; normalmente, a parte quanto vedremo in -sez.~\ref{sec:file_special_perm}, l'user-ID effettivo e il group-ID effettivo +sez.~\ref{sec:file_special_perm}, l'\acr{uid} effettivo e il \acr{gid} effettivo corrispondono ai valori dell'\acr{uid} e del \acr{gid} dell'utente che ha -lanciato il processo, mentre i group-ID supplementari sono quelli dei gruppi +lanciato il processo, mentre i \acr{gid} supplementari sono quelli dei gruppi cui l'utente appartiene. I passi attraverso i quali viene stabilito se il processo possiede il diritto di accesso sono i seguenti: \begin{enumerate} -\item Se l'user-ID effettivo del processo è zero (corrispondente +\item Se l'\acr{uid} effettivo del processo è zero (corrispondente all'amministratore) l'accesso è sempre garantito senza nessun ulteriore controllo. Per questo motivo \textsl{root} ha piena libertà di accesso a tutti i file. -\item Se l'user-ID effettivo del processo è uguale all'\acr{uid} del +\item Se l'\acr{uid} effettivo del processo è uguale all'\acr{uid} del proprietario del file (nel qual caso si dice che il processo è proprietario del file) allora: \begin{itemize*} @@ -2387,7 +2387,7 @@ di accesso sono i seguenti: impostato, l'accesso è consentito \item altrimenti l'accesso è negato \end{itemize*} -\item Se il group-ID effettivo del processo o uno dei group-ID supplementari +\item Se il \acr{gid} effettivo del processo o uno dei \acr{gid} supplementari dei processi corrispondono al \acr{gid} del file allora: \begin{itemize*} \item se il bit dei permessi d'accesso del gruppo è impostato, l'accesso è @@ -2429,9 +2429,9 @@ corrispondono a quelli dell'utente con cui si è entrati nel sistema. Se però il file del programma (che ovviamente deve essere eseguibile\footnote{per motivi di sicurezza il kernel ignora i bit \acr{suid} e \acr{sgid} per gli script eseguibili.}) ha il bit \acr{suid} impostato, il -kernel assegnerà come user-ID effettivo al nuovo processo l'\acr{uid} del +kernel assegnerà come \acr{uid} effettivo al nuovo processo l'\acr{uid} del proprietario del file al posto dell'\acr{uid} del processo originario. Avere -il bit \acr{sgid} impostato ha lo stesso effetto sul group-ID effettivo del +il bit \acr{sgid} impostato ha lo stesso effetto sul \acr{gid} effettivo del processo. I bit \acr{suid} e \acr{sgid} vengono usati per permettere agli utenti normali @@ -2528,9 +2528,9 @@ consapevolmente, cancellare i file temporanei creati degli altri utenti. \label{sec:file_perm_management} Come visto in sez.~\ref{sec:file_access_control} il controllo di accesso ad un -file viene fatto utilizzando l'user-ID ed il group-ID effettivo del processo; -ci sono casi però in cui si può voler effettuare il controllo con l'user-ID -reale ed il group-ID reale, vale a dire usando i valori di \acr{uid} e +file viene fatto utilizzando l'\acr{uid} ed il \acr{gid} effettivo del processo; +ci sono casi però in cui si può voler effettuare il controllo con l'\acr{uid} +reale ed il \acr{gid} reale, vale a dire usando i valori di \acr{uid} e \acr{gid} relativi all'utente che ha lanciato il programma, e che, come accennato in sez.~\ref{sec:file_special_perm} e spiegato in dettaglio in sez.~\ref{sec:proc_perms}, non è detto siano uguali a quelli effettivi. @@ -2621,7 +2621,7 @@ filename e su un file descriptor, i loro prototipi sono: \bodydesc{Le funzioni restituiscono zero in caso di successo e -1 per un errore, in caso di errore \var{errno} può assumere i valori: \begin{errlist} - \item[\errcode{EPERM}] l'user-ID effettivo non corrisponde a quello del + \item[\errcode{EPERM}] l'\acr{uid} effettivo non corrisponde a quello del proprietario del file o non è zero. \item[\errcode{EROFS}] il file è su un filesystem in sola lettura. \end{errlist} @@ -2685,7 +2685,7 @@ bit \itindex{suid~bit} \acr{suid} il valore da fornire sarebbe $4755$. Il cambiamento dei permessi di un file eseguito attraverso queste funzioni ha comunque alcune limitazioni, previste per motivi di sicurezza. L'uso delle -funzioni infatti è possibile solo se l'user-ID effettivo del processo +funzioni infatti è possibile solo se l'\acr{uid} effettivo del processo corrisponde a quello del proprietario del file o dell'amministratore, altrimenti esse falliranno con un errore di \errcode{EPERM}. @@ -2695,7 +2695,7 @@ non tutti i valori possibili di \param{mode} sono permessi o hanno effetto; in particolare accade che: \begin{enumerate} \item siccome solo l'amministratore può impostare lo \itindex{sticky~bit} - \textit{sticky bit}, se l'user-ID effettivo del processo non è zero esso + \textit{sticky bit}, se l'\acr{uid} effettivo del processo non è zero esso viene automaticamente cancellato (senza notifica di errore) qualora sia stato indicato in \param{mode}. \item per quanto detto in sez.~\ref{sec:file_ownership_management} riguardo la @@ -2705,7 +2705,7 @@ in particolare accade che: un file appartenente ad un gruppo per cui non si hanno diritti, questo viene automaticamente cancellato da \param{mode} (senza notifica di errore) qualora il gruppo del file non corrisponda a quelli associati al processo - (la cosa non avviene quando l'user-ID effettivo del processo è zero). + (la cosa non avviene quando l'\acr{uid} effettivo del processo è zero). \end{enumerate} Per alcuni filesystem\footnote{i filesystem più comuni (\textsl{ext2}, @@ -2779,10 +2779,10 @@ per la creazione di nuove directory (procedimento descritto in sez.~\ref{sec:file_dir_creat_rem}). Lo standard POSIX prescrive che l'\acr{uid} del nuovo file corrisponda -all'user-ID effettivo del processo che lo crea; per il \acr{gid} invece prevede +all'\acr{uid} effettivo del processo che lo crea; per il \acr{gid} invece prevede due diverse possibilità: \begin{itemize*} -\item il \acr{gid} del file corrisponde al group-ID effettivo del processo. +\item il \acr{gid} del file corrisponde al \acr{gid} effettivo del processo. \item il \acr{gid} del file corrisponde al \acr{gid} della directory in cui esso è creato. \end{itemize*} @@ -2833,7 +2833,7 @@ l'utente che il gruppo a cui un file appartiene; i rispettivi prototipi sono: \bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 per un errore, nel qual caso caso \var{errno} assumerà i valori: \begin{errlist} - \item[\errcode{EPERM}] l'user-ID effettivo non corrisponde a quello del + \item[\errcode{EPERM}] l'\acr{uid} effettivo non corrisponde a quello del proprietario del file o non è zero, o utente e gruppo non sono validi \end{errlist} Oltre a questi entrambe restituiscono gli errori \errval{EROFS} e @@ -3064,7 +3064,7 @@ classi di attributi riportate in tab.~\ref{tab:extended_attribute_class}. sez.~\ref{sec:proc_capabilities}.\\ \texttt{system} & Gli \textit{extended security attributes}: sono usati dal kernel per memorizzare dati di sistema associati ai - file come le \itindex{Access~Control~List} ACL (vedi + file come le \itindex{Access~Control~List~(ACL)} ACL (vedi sez.~\ref{sec:file_ACL}) o le \itindex{capabilities} \textit{capabilities} (vedi sez.~\ref{sec:proc_capabilities}).\\ @@ -3086,13 +3086,13 @@ classi di attributi riportate in tab.~\ref{tab:extended_attribute_class}. Dato che uno degli usi degli \textit{Extended Attributes} è quello che li -impiega per realizzare delle estensioni (come le \itindex{Access~Control~List} -ACL, \index{SELinux} SELinux, ecc.) al tradizionale meccanismo dei controlli -di accesso di Unix, l'accesso ai loro valori viene regolato in maniera diversa -a seconda sia della loro classe sia di quali, fra le estensioni che li -utilizzano, sono poste in uso. In particolare, per ciascuna delle classi -riportate in tab.~\ref{tab:extended_attribute_class}, si hanno i seguenti -casi: +impiega 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 sia +di quali, fra le estensioni che li utilizzano, sono poste in uso. In +particolare, per ciascuna delle classi riportate in +tab.~\ref{tab:extended_attribute_class}, si hanno i seguenti casi: \begin{basedescript}{\desclabelwidth{1.7cm}\desclabelstyle{\nextlinelabel}} \item[\texttt{security}] L'accesso agli \textit{extended security attributes} dipende dalle politiche di sicurezza stabilite da loro stessi tramite @@ -3109,12 +3109,13 @@ casi: \item[\texttt{system}] Anche l'accesso agli \textit{extended system attributes} dipende dalle politiche di accesso che il kernel realizza anche utilizzando gli stessi valori in essi contenuti. Ad esempio nel caso - delle \itindex{Access~Control~List} ACL l'accesso è consentito in lettura ai - processi che hanno la capacità di eseguire una ricerca sul file (cioè hanno - il permesso di lettura sulla directory che contiene il file) ed in scrittura - al proprietario del file o ai processi dotati della \textit{capability} - \index{capabilities} \const{CAP\_FOWNER}.\footnote{vale a dire una politica - di accesso analoga a quella impiegata per gli ordinari permessi dei file.} + 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} \index{capabilities} \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 @@ -3376,7 +3377,7 @@ illustrate in precedenza per le altre funzioni relative agli attributi estesi. % la documentazione di sistema è nei pacchetti libacl1-dev e acl % vedi anche http://www.suse.de/~agruen/acl/linux-acls/online/ -\itindbeg{Access~Control~List} +\itindbeg{Access~Control~List~(ACL)} Il modello classico dei permessi di Unix, per quanto funzionale ed efficiente, è comunque piuttosto limitato e per quanto possa aver coperto per lunghi anni @@ -3543,15 +3544,15 @@ identificatori del gruppo \textit{effective} del processo, ma in presenza di ACL i passi attraverso i quali viene stabilito se esso ha diritto di accesso sono i seguenti: \begin{enumerate*} -\item Se l'user-ID del processo è nullo l'accesso è sempre garantito senza +\item Se l'\acr{uid} del processo è nullo l'accesso è sempre garantito senza nessun controllo. -\item Se l'user-ID del processo corrisponde al proprietario del file allora: +\item Se l'\acr{uid} del processo corrisponde al proprietario del file allora: \begin{itemize*} \item se la voce \const{ACL\_USER\_OBJ} contiene il permesso richiesto, l'accesso è consentito; \item altrimenti l'accesso è negato. \end{itemize*} -\item Se l'user-ID del processo corrisponde ad un qualunque qualificatore +\item Se l'\acr{uid} del processo corrisponde ad un qualunque qualificatore presente in una voce \const{ACL\_USER} allora: \begin{itemize*} \item se la voce \const{ACL\_USER} corrispondente e la voce @@ -3559,7 +3560,7 @@ sono i seguenti: consentito; \item altrimenti l'accesso è negato. \end{itemize*} -\item Se è il group-ID del processo o uno dei group-ID supplementari +\item Se è il \acr{gid} del processo o uno dei \acr{gid} supplementari corrisponde al gruppo proprietario del file allora: \begin{itemize*} \item se la voce \const{ACL\_GROUP\_OBJ} e una eventuale voce @@ -3568,7 +3569,7 @@ sono i seguenti: l'accesso è consentito; \item altrimenti l'accesso è negato. \end{itemize*} -\item Se è il group-ID del processo o uno dei group-ID supplementari +\item Se è il \acr{gid} del processo o uno dei \acr{gid} supplementari corrisponde ad un qualunque qualificatore presente in una voce \const{ACL\_GROUP} allora: \begin{itemize*} @@ -3619,11 +3620,12 @@ mantenere i dati di una ACL contenente fino ad un massimo di \param{count} voci. La funzione ritorna un valore di tipo \type{acl\_t}, da usare in tutte le altre funzioni che operano sulla ACL. La funzione si limita alla allocazione iniziale e non inserisce nessun valore nella ACL che resta vuota. -Si tenga presente che pur essendo \type{acl\_t} un tipo opaco che identifica -``\textsl{l'oggetto}'' ACL, il valore restituito dalla funzione non è altro -che un puntatore all'area di memoria allocata per i dati richiesti; pertanto -in caso di fallimento verrà restituito un puntatore nullo e si dovrà -confrontare il valore di ritorno della funzione con ``\code{(acl\_t) NULL}''. +Si tenga presente che pur essendo \type{acl\_t} un \index{tipo!opaco} tipo +opaco che identifica ``\textsl{l'oggetto}'' ACL, il valore restituito dalla +funzione non è altro che un puntatore all'area di memoria allocata per i dati +richiesti; pertanto in caso di fallimento verrà restituito un puntatore nullo +e si dovrà confrontare il valore di ritorno della funzione con +``\code{(acl\_t) NULL}''. Una volta che si siano completate le operazioni sui dati di una ACL la memoria allocata dovrà essere liberata esplicitamente attraverso una chiamata alla @@ -3911,7 +3913,7 @@ tab.~\ref{tab:acl_to_text_options}. \hline \const{TEXT\_ABBREVIATE} & stampa le voci in forma abbreviata.\\ \const{TEXT\_NUMERIC\_IDS} & non effettua la risoluzione numerica di - user-ID e group-ID.\\ + \acr{uid} e \acr{gid}.\\ \const{TEXT\_SOME\_EFFECTIVE}& per ciascuna voce che contiene permessi che vengono eliminati dalla \const{ACL\_MASK} viene generato un commento con i permessi @@ -4144,7 +4146,7 @@ vengono utilizzati tipi di dato ad hoc.\footnote{descritti nelle singole ad un altra con \funcd{acl\_copy\_entry} o eliminare una voce da una ACL con \funcd{acl\_delete\_entry}. -\itindend{Access~Control~List} +\itindend{Access~Control~List~(ACL)} \subsection{La gestione delle quote disco} @@ -4368,7 +4370,7 @@ singolo utente. \begin{figure}[!htb] \footnotesize \centering - \begin{minipage}[c]{15cm} + \begin{minipage}[c]{\textwidth} \includestruct{listati/dqblk.h} \end{minipage} \normalsize @@ -4457,7 +4459,7 @@ fig.~\ref{fig:dqinfo_struct}. \begin{figure}[!htb] \footnotesize \centering - \begin{minipage}[c]{15cm} + \begin{minipage}[c]{\textwidth} \includestruct{listati/dqinfo.h} \end{minipage} \normalsize @@ -4506,9 +4508,9 @@ all'indirizzo \url{http://labs.truelite.it/projects/packages}.\footnote{in visionabile a partire dall'indirizzo indicato nella sezione \textit{Repository}.} -\begin{figure}[!htb] +\begin{figure}[!htbp] \footnotesize \centering - \begin{minipage}[c]{15.6cm} + \begin{minipage}[c]{\codesamplewidth} \includecodesample{listati/get_quota.c} \end{minipage} \caption{Esempio di codice per ottenere i dati delle quote.} @@ -4541,9 +4543,9 @@ relativi a uso corrente e limiti sia per i blocchi che per gli \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}[!htb] +\begin{figure}[!htbp] \footnotesize \centering - \begin{minipage}[c]{15.6cm} + \begin{minipage}[c]{\codesamplewidth} \includecodesample{listati/set_block_quota.c} \end{minipage} \caption{Esempio di codice per impostare i limiti sullo spazio disco.} @@ -4795,7 +4797,7 @@ 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}. -\begin{figure}[!htb] +\begin{figure}[!htbp] \footnotesize \centering \begin{minipage}[c]{12cm} \includecodesnip{listati/cap-results.c} @@ -4817,7 +4819,7 @@ nell'esecuzione di un qualunque programma l'amministratore perderebbe tutti i privilegi originali dal processo. Per questo motivo se un programma senza \textit{capabilities} assegnate viene -eseguito da un processo con \textit{real user-ID} 0, esso verrà trattato come +eseguito da un processo con \acr{uid} reale 0, esso verrà trattato come se tanto il \textit{permitted set} che l'\textit{inheritable set} fossero con tutte le \textit{capabilities} abilitate, con l'\textit{effective set} attivo, col risultato di fornire comunque al processo tutte le capacità presenti nel @@ -4826,19 +4828,19 @@ il \acr{suid} bit ed appartiene all'amministratore, in entrambi i casi si riesce così a riottenere il comportamento classico di un sistema unix-like. Una seconda circostanza è quella relativa a cosa succede alle -\textit{capabilities} di un processo nelle possibili transizioni da -\textit{user-ID} nullo a \textit{user-ID} non nullo o viceversa (corrispondenti -rispettivamente a cedere o riottenere i i privilegi di amministratore) che si -possono effettuare con le varie funzioni viste in -sez.~\ref{sec:proc_setuid}. In questo caso la casistica è di nuovo alquanto -complessa, considerata anche la presenza dei diversi gruppi di identificatori -illustrati in tab.~\ref{tab:proc_uid_gid}, si avrà allora che: +\textit{capabilities} di un processo nelle possibili transizioni da \acr{uid} +nullo a \acr{uid} non nullo o viceversa (corrispondenti rispettivamente a +cedere o riottenere i i privilegi di amministratore) che si possono effettuare +con le varie funzioni viste in sez.~\ref{sec:proc_setuid}. In questo caso la +casistica è di nuovo alquanto complessa, considerata anche la presenza dei +diversi gruppi di identificatori illustrati in tab.~\ref{tab:proc_uid_gid}, si +avrà allora che: \begin{enumerate*} -\item se si passa da \textit{effective user-ID} nullo a non nullo +\item se si passa da \acr{uid} effettivo nullo a non nullo l'\textit{effective set} del processo viene totalmente azzerato, se - viceversa si passa da \textit{effective user-ID} non nullo a nullo il + viceversa si passa da \acr{uid} effettivo non nullo a nullo il \textit{permitted set} viene copiato nell'\textit{effective set}; -\item se si passa da \textit{file system user-ID} nullo a non nullo verranno +\item se si passa da \textit{file system} \acr{uid} nullo a non nullo verranno cancellate dall'\textit{effective set} del processo tutte le capacità attinenti i file, e cioè \const{CAP\_LINUX\_IMMUTABLE}, \const{CAP\_MKNOD}, \const{CAP\_DAC\_OVERRIDE}, \const{CAP\_DAC\_READ\_SEARCH}, @@ -4870,10 +4872,10 @@ cancellarle dal \textit{permitted set}. Per questo motivo a partire dal kernel 2.6.26, se le \textit{file capabilities} sono abilitate, ad ogni processo viene stata associata una -ulteriore maschera binaria, chiamata \textit{securebits flags}, il cui sono +ulteriore maschera binaria, chiamata \textit{securebits flags}, su cui sono mantenuti una serie di flag (vedi tab.~\ref{tab:securebits_values}) il cui valore consente di modificare queste regole speciali che si applicano ai -processi con \textit{user-ID} nullo. La maschera viene sempre mantenuta +processi con \acr{uid} nullo. La maschera viene sempre mantenuta attraverso una \func{fork}, mentre attraverso una \func{exec} viene sempre cancellato il flag \const{SECURE\_KEEP\_CAPS}. @@ -4887,22 +4889,22 @@ cancellato il flag \const{SECURE\_KEEP\_CAPS}. \hline \const{SECURE\_KEEP\_CAPS}& Il processo non subisce la cancellazione delle sue \textit{capabilities} quando tutti i suoi - \textit{user-ID} passano ad un valore non + \acr{uid} passano ad un valore non nullo (regola di compatibilità per il cambio - di \textit{user-ID} n. 3 del precedente + di \acr{uid} n.~3 del precedente elenco), sostituisce il precedente uso dell'operazione \const{PR\_SET\_KEEPCAPS} di \func{prctl}.\\ \const{SECURE\_NO\_SETUID\_FIXUP}&Il processo non subisce le modifiche delle sue \textit{capabilities} nel passaggio - da nullo a non nullo degli \textit{user-ID} + da nullo a non nullo degli \acr{uid} dei gruppi \textit{effective} e \textit{file system} (regole di compatibilità - per il cambio di \textit{user-ID} nn. 1 e 2 del + per il cambio di \acr{uid} nn.~1 e 2 del precedente elenco).\\ \const{SECURE\_NOROOT} & Il processo non assume nessuna capacità aggiuntiva quando esegue un programma, anche - se ha \textit{user-ID} nullo o il programma ha + se ha \acr{uid} nullo o il programma ha il \acr{suid} bit attivo ed appartiene all'amministratore (regola di compatibilità per l'esecuzione di programmi senza @@ -5138,13 +5140,13 @@ 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 processo che non ha la proprietà di un file in un vasto campo di -operazioni;\footnote{vale a dire la richiesta che l'user-ID effettivo del - processo (o meglio il \textit{filesystem user-ID}, vedi +operazioni;\footnote{vale a dire la richiesta che l'\acr{uid} effettivo del + processo (o meglio l'\acr{uid} di filesystem, vedi sez.~\ref{sec:proc_setuid}) coincida con quello del proprietario.} queste comprendono i cambiamenti dei permessi e dei tempi del file (vedi sez.~\ref{sec:file_perm_management} e sez.~\ref{sec:file_file_times}), le -impostazioni degli attributi estesi e delle ACL (vedi -sez.~\ref{sec:file_xattr} e \ref{sec:file_ACL}), poter ignorare lo +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 \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 @@ -5164,7 +5166,7 @@ disattivare la swap, montare, rimontare e smontare filesystem (vedi sez.~\ref{sec:sys_file_config}), effettuare operazioni di controllo su qualunque oggetto dell'IPC di SysV (vedi sez.~\ref{sec:ipc_sysv}), operare sugli attributi estesi dei file di classe \texttt{security} o \texttt{trusted} -(vedi sez.~\ref{sec:file_xattr}), specificare un \textit{user-ID} arbitrario +(vedi sez.~\ref{sec:file_xattr}), specificare un \acr{uid} arbitrario nella trasmissione delle credenziali dei socket (vedi sez.~\ref{sec:socket_credential_xxx}), assegnare classi privilegiate (\const{IOPRIO\_CLASS\_RT} e prima del kernel 2.6.25 anche @@ -5173,7 +5175,7 @@ sez.~\ref{sec:io_priority}), superare il limite di sistema sul numero massimo di file aperti,\footnote{quello indicato da \procfile{/proc/sys/fs/file-max}.} effettuare operazioni privilegiate sulle chiavi mantenute dal kernel (vedi sez.~\ref{sec:keyctl_management}), usare la funzione \func{lookup\_dcookie}, -usare \const{CLONE\_NEWNS} con \func{unshare}, (vedi +usare \const{CLONE\_NEWNS} con \func{unshare} e \func{clone}, (vedi sez.~\ref{sec:process_clone}). Originariamente \const{CAP\_SYS\_NICE} riguardava soltanto la capacità di @@ -5196,7 +5198,6 @@ risorse di un processo (vedi sez.~\ref{sec:sys_resource_limit}) e quelle sul numero di processi, ed i limiti sulle dimensioni dei messaggi delle code del SysV IPC (vedi sez.~\ref{sec:ipc_sysv_mq}). - 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} @@ -5226,7 +5227,6 @@ loro rispettivi prototipi sono: \end{errlist} ed inoltre \errval{EFAULT} ed \errval{EINVAL}. } - \end{functions} Queste due funzioni prendono come argomenti due tipi di dati dedicati, @@ -5251,7 +5251,7 @@ utilizzare le interfacce di alto livello che vedremo più avanti. \begin{figure}[!htb] \footnotesize \centering - \begin{minipage}[c]{15cm} + \begin{minipage}[c]{\textwidth} \includestruct{listati/cap_user_header_t.h} \end{minipage} \normalsize @@ -5293,17 +5293,18 @@ una libreria a parte,\footnote{la libreria è \texttt{libcap2}, nel caso di programma le utilizza si dovrà indicare esplicitamente l'uso della suddetta libreria attraverso l'opzione \texttt{-lcap} del compilatore. -Le funzioni dell'interfaccia delle bozze di POSIX.1e prevedono l'uso di uno -tipo di dato opaco, \type{cap\_t}, come puntatore ai dati mantenuti nel -cosiddetto \textit{capability state},\footnote{si tratta in sostanza di un - puntatore ad una struttura interna utilizzata dalle librerie, i cui campi - non devono mai essere acceduti direttamente.} in sono memorizzati tutti i -dati delle \textit{capabilities}. In questo modo è possibile mascherare i -dettagli della gestione di basso livello, che potranno essere modificati senza -dover cambiare le funzioni dell'interfaccia, che faranno riferimento soltanto -ad oggetti di questo tipo. L'interfaccia pertanto non soltanto fornisce le -funzioni per modificare e leggere le \textit{capabilities}, ma anche quelle -per gestire i dati attraverso \type{cap\_t}. +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}. La prima funzione dell'interfaccia è quella che permette di inizializzare un \textit{capability state}, allocando al contempo la memoria necessaria per i @@ -5433,8 +5434,9 @@ di tipo \type{cap\_flag\_t} che può assumere esclusivamente\footnote{si tratta definizione che si trova in \texttt{/usr/include/sys/capability.h}.} uno dei valori illustrati in tab.~\ref{tab:cap_set_identifier}. -Si possono inoltre confrontare in maniera diretta due \textit{capability - state} con la funzione \funcd{cap\_compare}; il suo prototipo è: +Si possono inoltre confrontare in maniera diretta due diversi +\textit{capability state} con la funzione \funcd{cap\_compare}; il suo +prototipo è: \begin{functions} \headdecl{sys/capability.h} \funcdecl{int cap\_compare(cap\_t cap\_a, cap\_t cap\_b)} @@ -5539,9 +5541,10 @@ tab.~\ref{tab:cap_value_type}. Per semplificare la gestione delle \textit{capabilities} l'interfaccia prevede che sia possibile utilizzare anche una rappresentazione testuale del contenuto -di un \textit{capability state} e fornisce le opportune funzioni di gestione; -la prima di queste, che consente di ottenere la rappresentazione testuale, è -\funcd{cap\_to\_text}, il cui prototipo è: +di un \textit{capability state} e fornisce le opportune funzioni di +gestione;\footnote{entrambe erano previste dalla bozza dello standard + POSIX.1e.} la prima di queste, che consente di ottenere la rappresentazione +testuale, è \funcd{cap\_to\_text}, il cui prototipo è: \begin{functions} \headdecl{sys/capability.h} @@ -5574,7 +5577,7 @@ Ciascuna proposizione è nella forma di un elenco di capacità, espresso con i nomi di tab.~\ref{tab:proc_capabilities} separati da virgole, seguito da un operatore, e dall'indicazione degli insiemi a cui l'operazione si applica. I nomi delle capacità possono essere scritti sia maiuscoli che minuscoli, viene -inoltre riconosciuto il nome speciale \texttt{all} che è equivalmente a +inoltre riconosciuto il nome speciale \texttt{all} che è equivalente a 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 @@ -5589,32 +5592,81 @@ o negli insiemi specificati, ignorando tutto il resto. I due operatori possono anche essere combinati nella stessa proposizione, per aggiungere e togliere le capacità dell'elenco da insiemi diversi. -La assegnazione si applica invece su tutti gli insiemi allo stesso tempo, +L'assegnazione si applica invece su tutti gli insiemi allo stesso tempo, pertanto l'uso di ``\texttt{=}'' è equivalente alla cancellazione preventiva di tutte le capacità ed alla impostazione di quelle elencate negli insiemi -specificati, pertanto in genere lo si usa una sola volta all'inizio della -stringa. In tal caso l'elenco delle capacità può non essere indicato e viene -assunto che si stia facendo riferimento a tutte quante senza doverlo scrivere -esplicitamente. +specificati, questo significa che in genere lo si usa una sola volta +all'inizio della stringa. In tal caso l'elenco delle capacità può non essere +indicato e viene assunto che si stia facendo riferimento a tutte quante senza +doverlo scrivere esplicitamente. Come esempi avremo allora che un processo non privilegiato di un utente, che non ha nessuna capacità attiva, avrà una rappresentazione nella forma ``\texttt{=}'' che corrisponde al fatto che nessuna capacità viene assegnata a nessun insieme (vale la cancellazione preventiva), mentre un processo con privilegi di amministratore avrà una rappresentazione nella forma -``\texttt{=ep}'' in cui tutte le capacità vengono assegnati agli insiemi -\textit{permitted} ed \textit{effective} (l' \textit{inheritable} è ignorato +``\texttt{=ep}'' in cui tutte le capacità vengono assegnate agli insiemi +\textit{permitted} ed \textit{effective} (e l'\textit{inheritable} è ignorato in quanto per le regole viste a pag.~\ref{sec:capability-uid-transition} le -capacità verranno attivate attraverso una \func{exec}). Infine, come esempio -meno banale, otterremo per \texttt{init} una rappresentazione nella forma -``\texttt{=ep cap\_setpcap-e}'' dato che come accennato tradizionalmente -\const{CAP\_SETPCAP} è sempre stata rimossa da detto processo. +capacità verranno comunque attivate attraverso una \func{exec}). Infine, come +esempio meno banale dei precedenti, otterremo per \texttt{init} una +rappresentazione nella forma ``\texttt{=ep cap\_setpcap-e}'' dato che come +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 è: +\begin{functions} + \headdecl{sys/capability.h} + + \funcdecl{cap\_t cap\_from\_text(const char *string)} + + Crea un \textit{capability state} dalla sua rappresentazione testuale. + + \bodydesc{La funzione ritorna un puntatore valido in caso di successo e + \val{NULL} in caso di errore, nel qual caso \var{errno} può assumere i + valori \errval{EINVAL} o \errval{ENOMEM}.} +\end{functions} + +La funzione restituisce il puntatore ad un \textit{capability state} +inizializzato con i valori indicati nella stringa \param{string} che ne +contiene la rappresentazione testuale. La memoria per il \textit{capability + state} viene allocata automaticamente dalla funzione e dovrà essere liberata +con \func{cap\_free}. + +Alle due funzioni citate se ne aggiungono altre due che consentono di +convertire i valori delle costanti di tab.~\ref{tab:proc_capabilities} nelle +stringhe usate nelle rispettive rappresentazioni e viceversa. Le due funzioni, +\func{cap\_to\_name} e \func{cap\_from\_name}, sono estensioni specifiche di +Linux ed i rispettivi prototipi sono: +\begin{functions} + \headdecl{sys/capability.h} + + \funcdecl{char * cap\_to\_name(cap\_value\_t cap)} + \funcdecl{int cap\_from\_name(const char *name, cap\_value\_t *cap\_p)} + Convertono le \textit{capabilities} dalle costanti alla rappresentazione + testuale e viceversa. + + \bodydesc{La funzione \func{cap\_to\_name} ritorna un valore diverso da + \val{NULL} in caso di successo e \val{NULL} in caso di errore, mentre + \func{cap\_to\_name} ritorna rispettivamente 0 e $-1$; per entrambe in + caso di errore \var{errno} può assumere i valori \errval{EINVAL} o + \errval{ENOMEM}. } +\end{functions} + +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 +stringa \param{name}. Fin quei abbiamo trattato solo le funzioni di servizio relative alla -manipolazione dei \textit{capability state}; l'interfaccia di gestione prevede -però anche le funzioni per la gestione delle \textit{capabilities} stesse. La -prima di queste è \funcd{cap\_get\_proc} che consente la lettura delle -\textit{capabilities} del processo corrente, il suo prototipo è: +manipolazione dei \textit{capability state} come strutture di dati; +l'interfaccia di gestione prevede però anche le funzioni per trattare le +\textit{capabilities} presenti nei processi. La prima di queste funzioni è +\funcd{cap\_get\_proc} che consente la lettura delle \textit{capabilities} del +processo corrente, il suo prototipo è: \begin{functions} \headdecl{sys/capability.h} @@ -5703,9 +5755,9 @@ si è distribuito il programma \texttt{getcap.c}, che consente di leggere le dalla riga di comando.} o tramite l'opzione \texttt{-p}, quelle di un processo qualunque il cui pid viene passato come parametro dell'opzione. -\begin{figure}[htb] +\begin{figure}[!htbp] \footnotesize \centering - \begin{minipage}[c]{15cm} + \begin{minipage}[c]{\codesamplewidth} \includecodesample{listati/getcap.c} \end{minipage} \normalsize @@ -5783,7 +5835,7 @@ con la funzione \funcd{chroot}, il cui prototipo è: \bodydesc{La funzione restituisce zero in caso di successo e -1 per un errore, in caso di errore \var{errno} può assumere i valori: \begin{errlist} - \item[\errcode{EPERM}] l'user-ID effettivo del processo non è zero. + \item[\errcode{EPERM}] l'\acr{uid} effettivo del processo non è zero. \end{errlist} ed inoltre \errval{EFAULT}, \errval{ENAMETOOLONG}, \errval{ENOENT}, \errval{ENOMEM}, \errval{ENOTDIR}, \errval{EACCES}, \errval{ELOOP}; @@ -5884,7 +5936,7 @@ programmi e librerie) di cui il server potrebbe avere bisogno. % LocalWords: ptrace accounting NICE RESOURCE TTY CONFIG hangup vhangup dell' % LocalWords: LEASE lease SETFCAP AUDIT permitted inherited inheritable AND nn % LocalWords: bounding execve fork capget capset header hdrp datap ESRCH undef -% LocalWords: version libcap lcap clear ncap caps pag capgetp CapInh CapPrm +% LocalWords: version libcap lcap clear ncap caps pag capgetp CapInh CapPrm RT % LocalWords: fffffeff CapEff getcap scheduling lookup dqinfo SETINFO GETFMT % LocalWords: NEWNS unshare nice NUMA ioctl journaling close XOPEN fdopendir % LocalWords: btrfs mkostemp extN ReiserFS JFS Posix usrquota grpquota EDQUOT @@ -5895,7 +5947,8 @@ programmi e librerie) di cui il server potrebbe avere bisogno. % LocalWords: QIF BLIMITS bhardlimit bsoftlimit ILIMITS ihardlimit isoftlimit % LocalWords: INODES LIMITS USAGE valid dqi IIF BGRACE bgrace IGRACE igrace % LocalWords: Python Truelite Srl quotamodule Repository who nell' dall' KEEP -% LocalWords: SECURE KEEPCAPS prctl FIXUP NOROOT LOCKED dell'IPC dell'I +% LocalWords: SECURE KEEPCAPS prctl FIXUP NOROOT LOCKED dell'IPC dell'I IOPRIO +% LocalWords: CAPBSET CLASS IDLE dcookie overflow DIFFERS %%% Local Variables: %%% mode: latex