\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
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*}
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
\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.}
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},
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
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
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
\begin{figure}[!htb]
\footnotesize
\centering
- \begin{minipage}[c]{15cm}
+ \begin{minipage}[c]{\textwidth}
\includestruct{listati/cap_user_header_t.h}
\end{minipage}
\normalsize
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
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};
projects / gapil.git / blobdiff