\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
\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
\begin{figure}[!htb]
\footnotesize \centering
- \begin{minipage}[c]{15cm}
+ \begin{minipage}[c]{\textwidth}
\includestruct{listati/dirent.c}
\end{minipage}
\normalsize
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
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
\begin{figure}[!htb]
\footnotesize
\centering
- \begin{minipage}[c]{15cm}
+ \begin{minipage}[c]{\textwidth}
\includestruct{listati/stat.h}
\end{minipage}
\normalsize
\begin{figure}[!htb]
\footnotesize \centering
- \begin{minipage}[c]{15cm}
+ \begin{minipage}[c]{\textwidth}
\includestruct{listati/utimbuf.h}
\end{minipage}
\normalsize
\begin{figure}[!htb]
\footnotesize \centering
- \begin{minipage}[c]{15cm}
+ \begin{minipage}[c]{\textwidth}
\includestruct{listati/timeval.h}
\end{minipage}
\normalsize
\begin{figure}[!htb]
\footnotesize \centering
- \begin{minipage}[c]{15cm}
+ \begin{minipage}[c]{\textwidth}
\includestruct{listati/timespec.h}
\end{minipage}
\normalsize
Come per le precedenti funzioni il primo elemento di \param{times} indica il
tempo di ultimo accesso ed il secondo quello di ultima modifica, e se si usa
-il valore \const{NULL} verrà impostato il tempo corrente sia per l'ultimo
+il valore \val{NULL} verrà impostato il tempo corrente sia per l'ultimo
accesso che per l'ultima modifica. Nei singoli elementi di \param{times} si
possono inoltre utilizzare due valori speciali per il campo \var{tv\_nsec}:
con \const{UTIME\_NOW} si richiede l'uso del tempo corrente, mentre con
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,
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*}
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 è
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
\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.
\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}
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}.
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
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},
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*}
\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
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}).\\
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
\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
% 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
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
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
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*}
Inizializza un'area di lavoro per una ACL di \param{count} voci.
\bodydesc{La funzione restituisce un puntatore all'area di lavoro in caso di
- successo e \const{NULL} in caso di errore, nel qual caso \var{errno}
+ successo e \val{NULL} in caso di errore, nel qual caso \var{errno}
assumerà uno dei valori:
\begin{errlist}
\item[\errcode{EINVAL}] il valore di \param{count} è negativo.
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
Produce la rappresentazione testuale di una ACL.
\bodydesc{La funzione restituisce il puntatore ad una stringa con la
- rappresentazione testuale della ACL in caso di successo e \code{NULL} in
+ rappresentazione testuale della ACL in caso di successo e \val{NULL} in
caso di errore, nel qual caso \var{errno} assumerà uno dei valori:
\begin{errlist}
\item[\errcode{ENOMEM}] non c'è memoria sufficiente per allocare i dati.
\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
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}
\begin{figure}[!htb]
\footnotesize \centering
- \begin{minipage}[c]{15cm}
+ \begin{minipage}[c]{\textwidth}
\includestruct{listati/dqblk.h}
\end{minipage}
\normalsize
\begin{figure}[!htb]
\footnotesize \centering
- \begin{minipage}[c]{15cm}
+ \begin{minipage}[c]{\textwidth}
\includestruct{listati/dqinfo.h}
\end{minipage}
\normalsize
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.}
\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.}
2.6.25 il meccanismo delle \textit{capabilities} è stato totalmente
rivoluzionato, rendendolo più aderente alle intenzioni originali dello
standard POSIX, rimuovendo il significato che fino ad allora aveva avuto la
-capacità \macro{CAP\_SETPCAP} e cambiando le modalità di funzionamento del
+capacità \const{CAP\_SETPCAP} e cambiando le modalità di funzionamento del
cosiddetto \itindex{capabilities~bounding~set} \textit{capabilities bounding
set}. Ulteriori modifiche sono state apportate con il kernel 2.6.26 per
consentire la rimozione non ripristinabile dei privilegi di
eseguita con l'uso di uno specifico attributo esteso,
\texttt{security.capability}, la cui modifica è riservata, (come illustrato
in sez.~\ref{sec:file_xattr}) ai processi dotato della capacità
- \macro{CAP\_SYS\_ADMIN}.} Le \textit{file capabilities} hanno effetto
+ \const{CAP\_SYS\_ADMIN}.} Le \textit{file capabilities} hanno effetto
soltanto quando il file che le porta viene eseguito come programma con una
\func{exec}, e forniscono un meccanismo che consente l'esecuzione dello stesso
con maggiori privilegi; in sostanza sono una sorta di estensione del
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}
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
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},
quelle capacità della precedente lista che sono presenti nel suo
\textit{permitted set}.
\item se come risultato di una transizione riguardante gli identificativi dei
- gruppi \texttt{real}, \textit{saved} ed \textit{effective} in cui si passa
+ gruppi \textit{real}, \textit{saved} ed \textit{effective} in cui si passa
da una situazione in cui uno di questi era nullo ad una in cui sono tutti
non nulli,\footnote{in sostanza questo è il caso di quando si chiama
\func{setuid} per rimuovere definitivamente i privilegi di amministratore
da un processo.} verranno azzerati completamente sia il \textit{permitted
set} che l'\textit{effective set}.
\end{enumerate*}
+\label{sec:capability-uid-transition}
La combinazione di tutte queste regole consente di riprodurre il comportamento
ordinario di un sistema di tipo Unix tradizionale, ma può risultare
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}.
\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
\const{CAP\_SETPCAP} & La capacità di modifiche privilegiate alle
\textit{capabilities}.\\
\const{CAP\_SYS\_ADMIN} & La capacità di eseguire una serie di compiti
- amministrativi. \\
+ amministrativi.\\
\const{CAP\_SYS\_BOOT} & La capacità di fare eseguire un riavvio del
- sistema.\\
-% TODO trattare reboot e kexec
+ sistema (vedi sez.~\ref{sec:sys_reboot}).\\
\const{CAP\_SYS\_CHROOT}& La capacità di eseguire la funzione
- \func{chroot} (vedi
- sez.~\ref{sec:file_chroot}).\\
+ \func{chroot} (vedi sez.~\ref{sec:file_chroot}).\\
\const{CAP\_MAC\_ADMIN} & La capacità 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\_SYS\_MODULE}& La capacità di caricare e rimuovere moduli del
kernel.\\
\const{CAP\_SYS\_NICE} & La capacità di modificare le varie priorità dei
- processi.\\
+ processi (vedi sez.~\ref{sec:proc_priority}).\\
\const{CAP\_SYS\_PACCT} & La capacità di usare le funzioni di
\textit{accounting} dei processi (vedi
sez.~\ref{sec:sys_bsd_accounting}).\\
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
- \macro{CLOCK\_BOOTTIME\_ALARM} e
- \macro{CLOCK\_REALTIME\_ALARM}, vedi
+ \const{CLOCK\_BOOTTIME\_ALARM} e
+ \const{CLOCK\_REALTIME\_ALARM}, vedi
sez.~\ref{sec:sig_timer_adv} (dal kernel 3.0).\\
\hline
\end{tabular}
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
\const{CAP\_SYS\_ADMIN}, che copre una serie di operazioni amministrative,
come impostare le quote disco (vedi sez.\ref{sec:disk_quota}), attivare e
disattivare la swap, montare, rimontare e smontare filesystem (vedi
-sez.~\ref{sec:sys_file_config}), effettuare operazioni di controllo sugli
-oggetti dell'IPC di SysV (vedi sez.~\ref{sec:ipc_sysv}), operare sugli
-attributi estesi di classe \texttt{security} o \texttt{trusted} (vedi
-sez.~\ref{sec:file_xattr}), specificare un user-ID arbitrario nella
-trasmissione delle credenziali dei socket (vedi sez.~\ref{sec:socket_xxx}),
-assegnare classi privilegiate per lo scheduling dell'I/O (vedi
+sez.~\ref{sec: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 \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
+\const{IOPRIO\_CLASS\_IDLE}) per lo scheduling dell'I/O (vedi
sez.~\ref{sec:io_priority}), superare il limite di sistema sul numero massimo
di file aperti,\footnote{quello indicato da \procfile{/proc/sys/fs/file-max}.}
effettuare operazioni privilegiate sulle chiavi mantenute dal kernel (vedi
-sez.~\ref{sec:io_priority}), usare la funzione \func{lookup\_dcookie}, usare
-\const{CLONE\_NEWNS} con \func{unshare}, (vedi sez.~\ref{sec:process_clone}).
+sez.~\ref{sec:keyctl_management}), usare la funzione \func{lookup\_dcookie},
+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
aumentare le priorità di esecuzione dei processi, come la diminuzione del
lo spazio disco riservato all'amministratore sui filesystem che lo supportano,
usare la funzione \func{ioctl} per controllare il \textit{journaling} sul
filesystem \acr{ext3}, non subire le quote disco, aumentare i limiti sulle
-risorse (vedi sez.~\ref{sec:sys_resource_limit}) e sulle dimensioni dei
-messaggi delle code del SysV IPC (vedi sez.~\ref{sec:ipc_sysv_mq}).
-
-Questo modo di intendere ... da fare ... per cui
-a partire dal 2.6.24/5 è divenuta quella di impostare una capacità del
-\textit{bounding set} nelle proprie \textit{inheritable} o rimuoverla dal
-\textit{bounding set} stesso.
+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
\end{errlist}
ed inoltre \errval{EFAULT} ed \errval{EINVAL}.
}
-
\end{functions}
Queste due funzioni prendono come argomenti due tipi di dati dedicati,
definiti come puntatori a due strutture specifiche di Linux, illustrate in
-fig.~\ref{fig:cap_kernel_struct}. Per poterle utilizzare occorre anche
-cancellare la macro \macro{\_POSIX\_SOURCE}.\footnote{per farlo occorre
- utilizzare la direttiva di preprocessore \direct{undef}; si dovrà cioè
- inserire una istruzione \texttt{\#undef \_POSIX\_SOURCE} prima di includere
- \texttt{sys/capability.h}.} Si tenga presente che le strutture di
-fig.~\ref{fig:cap_kernel_struct}, come i prototipi delle due funzioni
-\func{capget} e \func{capset}, sono soggette ad essere modificate con il
-cambiamento del kernel (in particolare i tipi di dati delle strutture) ed
-anche se finora l'interfaccia è risultata stabile, non c'è nessuna
-assicurazione che questa venga mantenuta.\footnote{anzi, visto lo scarso
- utilizzo di questa funzionalità ci sono state varie discussioni fra gli
- sviluppatori del kernel relative all'eliminarla o al modificarla
- radicalmente.} Pertanto se si vogliono scrivere programmi portabili che
-possano essere eseguiti su qualunque versione del kernel è opportuno
-utilizzare le interfacce di alto livello.
+fig.~\ref{fig:cap_kernel_struct}. Per un certo periodo di tempo era anche
+indicato che per poterle utilizzare fosse necessario che la macro
+\macro{\_POSIX\_SOURCE} risultasse non definita (ed era richiesto di inserire
+una istruzione \texttt{\#undef \_POSIX\_SOURCE} prima di includere
+\texttt{sys/capability.h}) requisito che non risulta più 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]{15cm}
+ \begin{minipage}[c]{\textwidth}
\includestruct{listati/cap_user_header_t.h}
\end{minipage}
\normalsize
\end{figure}
La struttura a cui deve puntare l'argomento \param{hdrp} serve ad indicare,
-tramite il campo \var{pid}, il processo del quale si vogliono leggere o
-modificare le \textit{capabilities}. Il campo \var{version} deve essere
-impostato al valore della versione delle usata dal kernel (quello indicato
-dalla costante \const{\_LINUX\_CAPABILITY\_VERSION} di
+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 \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 \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 struttura a cui deve puntare l'argomento
-\param{datap} invece conterrà i valori letti o da impostare per i tre insiemi
-delle capacità del processo.
+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 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 puntatore \param{datap} non può essere più considerato come
+relativo ad una singola struttura, ma ad un vettore di due
+strutture.\footnote{è questo cambio di significato che ha portato a deprecare
+ la versione 2, che con \func{capget} poteva portare ad un buffer overflow
+ per vecchie applicazioni che continuavano a considerare \param{datap} come
+ puntatore ad una singola struttura.}
Dato che le precedenti funzioni, oltre ad essere specifiche di Linux, non
garantiscono la stabilità nell'interfaccia, è sempre opportuno effettuare la
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
Crea ed inizializza un \textit{capability state}.
\bodydesc{La funzione ritorna un valore non nullo in caso di successo e
- \macro{NULL} in caso di errore, nel qual caso \var{errno} assumerà il
+ \val{NULL} in caso di errore, nel qual caso \var{errno} assumerà il
valore \errval{ENOMEM}.
}
\end{functions}
La funzione restituisce il puntatore \type{cap\_t} ad uno stato inizializzato
con tutte le \textit{capabilities} azzerate. In caso di errore (cioè quando
-non c'è memoria sufficiente ad allocare i dati) viene restituito \macro{NULL}
+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
dovrà essere un dato di tipo \type{cap\_t}, che per una descrizione testuale
dello stesso,\footnote{cioè quanto ottenuto tramite la funzione
\func{cap\_to\_text}.} nel qual caso l'argomento dovrà essere un dato di
-tipo \texttt{char *}. Per questo l'argomento \param{obj\_d} è dichiarato come
-\texttt{void *} e deve sempre corrispondere ad un puntatore ottenuto tramite
-le altre funzioni della libreria, altrimenti la funzione fallirà con un errore
-di \errval{EINVAL}.
+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}.
Infine si può creare una copia di un \textit{capability state} ottenuto in
precedenza tramite la funzione \funcd{cap\_dup}, il cui prototipo è:
Duplica un \textit{capability state} restituendone una copia.
\bodydesc{La funzione ritorna un valore non nullo in caso di successo e
- \macro{NULL} in caso di errore, nel qual caso \var{errno} potrà assumere i
+ \val{NULL} in caso di errore, nel qual caso \var{errno} potrà assumere i
valori \errval{ENOMEM} o \errval{EINVAL}.
}
\end{functions}
restituendo uno stato \textsl{vuoto}, analogo a quello che si ottiene nella
creazione con \func{cap\_init}.
-Per la gestione dei valori delle \textit{capabilities} presenti in un
-\textit{capability state} l'interfaccia prevede due funzioni,
+\begin{table}[htb]
+ \centering
+ \footnotesize
+ \begin{tabular}[c]{|l|l|}
+ \hline
+ \textbf{Valore} & \textbf{Significato} \\
+ \hline
+ \hline
+ \const{CAP\_EFFECTIVE} & Capacità dell'insieme \textsl{effettivo}.\\
+ \const{CAP\_PERMITTED} & Capacità dell'insieme \textsl{permesso}.\\
+ \const{CAP\_INHERITABLE}& Capacità dell'insieme \textsl{ereditabile}.\\
+ \hline
+ \end{tabular}
+ \caption{Valori possibili per il tipo di dato \type{cap\_flag\_t} che
+ identifica gli insiemi delle \textit{capabilities}.}
+ \label{tab:cap_set_identifier}
+\end{table}
+
+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{functions}
+ \headdecl{sys/capability.h}
+
+ \funcdecl{int cap\_clear\_flag(cap\_t cap\_p, cap\_flag\_t flag)}
+
+ Cancella dal \textit{capability state} \param{cap\_p} tutte le
+ \textit{capabilities} dell'insieme \param{flag}.
+
+ \bodydesc{La funzione ritorna 0 in caso di successo e $-1$ in caso di
+ errore, nel qual caso \var{errno} assumerà il valore \errval{EINVAL}. }
+\end{functions}
+
+La funzione 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 \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 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)}
+
+ Confronta due \textit{capability state}.
+
+ \bodydesc{La funzione ritorna 0 se i \textit{capability state} sono identici
+ ed un valore positivo se differiscono, non sono previsti errori.}
+\end{functions}
+
+La funzione esegue un confronto fra i due \textit{capability state} passati
+come argomenti e ritorna in un valore intero il risultato, questo è nullo se
+sono identici o positivo se vi sono delle differenze. Il valore di ritorno
+della funzione consente inoltre di per ottenere ulteriori informazioni su
+quali sono gli insiemi di \textit{capabilities} che risultano differenti. Per
+questo si può infatti usare la apposita macro \macro{CAP\_DIFFERS}:
+\begin{functions}
+ \funcdecl{int CAP\_DIFFERS(value, flag)} Controlla lo stato di eventuali
+ differenze delle \textit{capabilities} nell'insieme \texttt{flag}.
+\end{functions}
+
+La macro che richiede 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
+\func{cap\_compare} sono presenti nell'insieme indicato.
+
+Per la gestione dei singoli valori delle \textit{capabilities} presenti in un
+\textit{capability state} l'interfaccia prevede due funzioni specifiche,
\funcd{cap\_get\_flag} e \funcd{cap\_set\_flag}, che permettono
-rispettivamente di leggere o impostare il valore di un flag delle
-\textit{capabilities}; i rispettivi prototipi sono:
+rispettivamente di leggere o impostare il valore di una capacità all'interno
+in uno dei tre insiemi già citati; i rispettivi prototipi sono:
\begin{functions}
\headdecl{sys/capability.h}
In entrambe le funzioni l'argomento \param{cap\_p} indica il puntatore al
\textit{capability state} su cui operare, mentre l'argomento \param{flag}
-indica su quale dei tre insiemi illustrati a
-pag.~\pageref{sec:capabilities_set} si intende operare. Questi devono essere
-specificati con una variabile di tipo \type{cap\_flag\_t} che può assumere
-esclusivamente\footnote{si tratta in effetti di un tipo enumerato, come si può
- verificare dalla sua definizione che si trova in
- \texttt{/usr/include/sys/capability.h}.} uno dei valori illustrati in
+indica su quale dei tre insiemi si intende operare, sempre con i valori di
tab.~\ref{tab:cap_set_identifier}.
-\begin{table}[htb]
- \centering
- \footnotesize
- \begin{tabular}[c]{|l|l|}
- \hline
- \textbf{Valore} & \textbf{Significato} \\
- \hline
- \hline
- \const{CAP\_EFFECTIVE} & Capacità dell'insieme \textsl{effettivo}.\\
- \const{CAP\_PERMITTED} & Capacità dell'insieme \textsl{permesso}.\\
- \const{CAP\_INHERITABLE}& Capacità dell'insieme \textsl{ereditabile}.\\
- \hline
- \end{tabular}
- \caption{Valori possibili per il tipo di dato \type{cap\_flag\_t} che
- identifica gli insiemi delle \textit{capabilities}.}
- \label{tab:cap_set_identifier}
-\end{table}
-
La capacità che si intende controllare o impostare invece deve essere
specificata attraverso una variabile di tipo \type{cap\_value\_t}, che può
prendere come valore uno qualunque di quelli riportati in
tab.~\ref{tab:proc_capabilities}, in questo caso però non è possibile
combinare diversi valori in una maschera binaria, una variabile di tipo
-\type{cap\_value\_t} deve indicare una sola capacità.\footnote{nel file di
- header citato nella nota precedente il tipo \type{cap\_value\_t} è definito
- come \ctyp{int}, ma i valori validi sono soltanto quelli di
- tab.~\ref{tab:proc_capabilities}.}
+\type{cap\_value\_t} può indicare una sola capacità.\footnote{in
+ \texttt{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}.}
Infine lo stato di una capacità è descritto ad una variabile di tipo
\type{cap\_flag\_value\_t}, che a sua volta può assumere soltanto
La funzione \func{cap\_get\_flag} legge lo stato della capacità indicata
dall'argomento \param{cap} all'interno dell'insieme indicato dall'argomento
-\param{flag} e ne restituisce il valore nella variabile posta all'indirizzo
-puntato dall'argomento \param{value\_p}; è possibile cioè leggere soltanto uno
-stato di una capacità alla volta.
+\param{flag} lo restituisce 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
+lo stato di una capacità alla volta.
La funzione \func{cap\_set\_flag} può invece impostare in una sola chiamata
-più \textit{capabilities}, anche se solo all'interno dello stesso insieme. Per
-questo motivo essa prende un vettore di valori di tipo \type{cap\_value\_t}
-nell'argomento \param{caps}, la cui dimensione viene specificata dall'argomento
-\param{ncap}. Il tipo di impostazione da eseguire (cancellazione o
-impostazione) viene indicato dall'argomento \param{value}.
-
-Per la visualizzazione dello stato delle \textit{capabilities} l'interfaccia
-prevede una funzione apposita, \funcd{cap\_to\_text}, il cui prototipo è:
+più \textit{capabilities}, anche se solo all'interno dello stesso insieme ed
+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
+indicato dall'argomento \param{value} sempre con i valori di
+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;\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}
\end{functions}
La funzione ritorna l'indirizzo di una stringa contente la descrizione
-testuale del contenuto del \textit{capabilities state} \param{caps} passato
-come argomento, e, qualora l'argomento \param{length\_p} sia diverso da
-\val{NULL}, restituisce nella variabile intera da questo puntata la lunghezza
-della stringa. La stringa restituita viene allocata automaticamente dalla
-funzione e pertanto dovrà essere liberata con \func{cap\_free}.
+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
+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
+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
+rappresentazione si fa sempre conto di partire da uno stato in cui tutti gli
+insiemi sono vuoti e si provvede a impostarne i contenuti.
+
+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 è 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
+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{=}''
+che le assegna esattamente. I primi due richiedono che sia sempre indicato sia
+un elenco di capacità che gli insiemi a cui esse devono applicarsi, e
+rispettivamente attiveranno o disattiveranno le capacità elencate nell'insieme
+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.
+
+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, 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 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 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{capabilities state}; l'interfaccia di gestione
-prevede però anche le funzioni per la gestione delle \textit{capabilities}
-stesse. La prima di queste è \funcd{cap\_get\_proc} che consente la lettura
-delle \textit{capabilities} del processo corrente, il suo prototipo è:
+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}
La funzione legge il valore delle \textit{capabilities} associate al processo
da cui viene invocata, restituendo il risultato tramite il puntatore ad un
-\textit{capabilities state} contenente tutti i dati che provvede ad allocare
+\textit{capability state} contenente tutti i dati che provvede ad allocare
autonomamente e che di nuovo occorrerà liberare con \func{cap\_free} quando
non sarà più utilizzato.
%TODO controllare e correggere i codici di errore!!!
La funzione legge il valore delle \textit{capabilities} del processo indicato
-con l'argomento \param{pid}, e restituisce il risultato nel
-\textit{capabilities state} posto all'indirizzo indicato con l'argomento
+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
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
\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};
% 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
% 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
projects / gapil.git / blobdiff