%% prochand.tex
%%
-%% Copyright (C) 2000-2005 Simone Piccardi. Permission is granted to
+%% Copyright (C) 2000-2007 Simone Piccardi. Permission is granted to
%% copy, distribute and/or modify this document under the terms of the GNU Free
%% Documentation License, Version 1.1 or any later version published by the
%% Free Software Foundation; with the Invariant Sections being "Un preambolo",
%% license is included in the section entitled "GNU Free Documentation
%% License".
%%
+
\chapter{La gestione dei processi}
\label{cha:process_handling}
\label{fig:proc_task_struct}
\end{figure}
-Come accennato in sez.~\ref{sec:intro_unix_struct} è lo
-\textit{scheduler}\itindex{scheduler} che decide quale processo mettere in
-esecuzione; esso viene eseguito ad ogni system call ed ad ogni
-interrupt,\footnote{più in una serie di altre occasioni.}
-% TODO completare questa parte.
+Come accennato in sez.~\ref{sec:intro_unix_struct} è lo \itindex{scheduler}
+\textit{scheduler} che decide quale processo mettere in esecuzione; esso viene
+eseguito ad ogni system call ed ad ogni interrupt,\footnote{più in una serie
+ di altre occasioni.}
+% TODO completare questa parte su quando viene chiamato lo scheduler.
(ma può essere anche attivato esplicitamente). Il timer di sistema provvede
comunque a che esso sia invocato periodicamente, generando un interrupt
periodico secondo la frequenza specificata dalla costante \const{HZ}, definita
in \file{asm/param.h}, ed il cui valore è espresso in Hertz.\footnote{Fino al
- kernel 2.4 l valore usuale di questa costante era 100, per tutte le
+ kernel 2.4 il valore usuale di questa costante era 100, per tutte le
architetture eccetto l'alpha, per la quale era 1000. Occorre fare attenzione
a non confondere questo valore con quello dei clock tick (vedi
sez.~\ref{sec:sys_unix_time}).}
% TODO verificare gli ultimi cambiamenti del 2.6
% Si ha cioè un interrupt dal timer ogni centesimo di secondo.
-Ogni volta che viene eseguito, lo \textit{scheduler}\itindex{scheduler}
+Ogni volta che viene eseguito, lo \itindex{scheduler} \textit{scheduler}
effettua il calcolo delle priorità dei vari processi attivi (torneremo su
questo in sez.~\ref{sec:proc_priority}) e stabilisce quale di essi debba
essere posto in esecuzione fino alla successiva invocazione.
candidato per generare ulteriori indicatori associati al processo di cui
diventa possibile garantire l'unicità: ad esempio in alcune implementazioni la
funzione \func{tempnam} (si veda sez.~\ref{sec:file_temp_file}) usa il
-\acr{pid} per generare un \itindex{pathname}\textit{pathname} univoco, che non
-potrà essere replicato da un altro processo che usi la stessa funzione.
+\acr{pid} per generare un \itindex{pathname} \textit{pathname} univoco, che
+non potrà essere replicato da un altro processo che usi la stessa funzione.
Tutti i processi figli dello stesso processo padre sono detti
\textit{sibling}, questa è una delle relazioni usate nel \textsl{controllo di
Dopo il successo dell'esecuzione di una \func{fork} sia il processo padre che
il processo figlio continuano ad essere eseguiti normalmente a partire
dall'istruzione successiva alla \func{fork}; il processo figlio è però una
-copia del padre, e riceve una copia dei segmenti di testo, \itindex{stack}
-stack e dati (vedi sez.~\ref{sec:proc_mem_layout}), ed esegue esattamente lo
-stesso codice del padre. Si tenga presente però che la memoria è copiata, non
-condivisa, pertanto padre e figlio vedono variabili diverse.
-
-Per quanto riguarda la gestione della memoria, in generale
-il\index{segmento!testo} segmento di testo, che è identico per i due processi,
-è condiviso e tenuto in read-only per il padre e per i figli. Per gli altri
-segmenti Linux utilizza la tecnica del \textit{copy on
- write}\itindex{copy~on~write}; questa tecnica comporta che una pagina di
-memoria viene effettivamente copiata per il nuovo processo solo quando ci
-viene effettuata sopra una scrittura (e si ha quindi una reale differenza fra
-padre e figlio). In questo modo si rende molto più efficiente il meccanismo
-della creazione di un nuovo processo, non essendo più necessaria la copia di
-tutto lo spazio degli indirizzi virtuali del padre, ma solo delle pagine di
-memoria che sono state modificate, e solo al momento della modifica stessa.
+copia del padre, e riceve una copia dei \index{segmento!testo} segmenti di
+testo, \itindex{stack} stack e \index{segmento!dati} dati (vedi
+sez.~\ref{sec:proc_mem_layout}), ed esegue esattamente lo stesso codice del
+padre. Si tenga presente però che la memoria è copiata, non condivisa,
+pertanto padre e figlio vedono variabili diverse.
+
+Per quanto riguarda la gestione della memoria, in generale il
+\index{segmento!testo} segmento di testo, che è identico per i due processi, è
+condiviso e tenuto in read-only per il padre e per i figli. Per gli altri
+segmenti Linux utilizza la tecnica del \itindex{copy~on~write} \textit{copy on
+ write}; questa tecnica comporta che una pagina di memoria viene
+effettivamente copiata per il nuovo processo solo quando ci viene effettuata
+sopra una scrittura (e si ha quindi una reale differenza fra padre e figlio).
+In questo modo si rende molto più efficiente il meccanismo della creazione di
+un nuovo processo, non essendo più necessaria la copia di tutto lo spazio
+degli indirizzi virtuali del padre, ma solo delle pagine di memoria che sono
+state modificate, e solo al momento della modifica stessa.
La differenza che si ha nei due processi è che nel processo padre il valore di
ritorno della funzione \func{fork} è il \acr{pid} del processo figlio, mentre
Esaminiamo questo risultato: una prima conclusione che si può trarre è che non
si può dire quale processo fra il padre ed il figlio venga eseguito per
primo\footnote{a partire dal kernel 2.5.2-pre10 è stato introdotto il nuovo
- scheduler\itindex{scheduler} di Ingo Molnar che esegue sempre per primo il
- figlio; per mantenere la portabilità è opportuno non fare comunque
+ \itindex{scheduler} \textit{scheduler} di Ingo Molnar che esegue sempre per
+ primo il figlio; per mantenere la portabilità è opportuno non fare comunque
affidamento su questo comportamento.} dopo la chiamata a \func{fork};
dall'esempio si può notare infatti come nei primi due cicli sia stato eseguito
per primo il padre (con la stampa del \acr{pid} del nuovo processo) per poi
(fino alla conclusione) e poi il padre.
In generale l'ordine di esecuzione dipenderà, oltre che dall'algoritmo di
-scheduling usato dal kernel, dalla particolare situazione in cui si trova la
-macchina al momento della chiamata, risultando del tutto impredicibile.
-Eseguendo più volte il programma di prova e producendo un numero diverso di
-figli, si sono ottenute situazioni completamente diverse, compreso il caso in
-cui il processo padre ha eseguito più di una \func{fork} prima che uno dei
-figli venisse messo in esecuzione.
+\itindex{scheduler} scheduling usato dal kernel, dalla particolare situazione
+in cui si trova la macchina al momento della chiamata, risultando del tutto
+impredicibile. Eseguendo più volte il programma di prova e producendo un
+numero diverso di figli, si sono ottenute situazioni completamente diverse,
+compreso il caso in cui il processo padre ha eseguito più di una \func{fork}
+prima che uno dei figli venisse messo in esecuzione.
Pertanto non si può fare nessuna assunzione sulla sequenza di esecuzione delle
istruzioni del codice fra padre e figli, né sull'ordine in cui questi potranno
essere messi in esecuzione. Se è necessaria una qualche forma di precedenza
occorrerà provvedere ad espliciti meccanismi di sincronizzazione, pena il
-rischio di incorrere nelle cosiddette \textit{race
- condition}\itindex{race~condition} (vedi sez.~\ref{sec:proc_race_cond}).
+rischio di incorrere nelle cosiddette \itindex{race~condition} \textit{race
+ condition} (vedi sez.~\ref{sec:proc_race_cond}).
Si noti inoltre che essendo i segmenti di memoria utilizzati dai singoli
processi completamente separati, le modifiche delle variabili nei processi
la caratteristica di duplicare nei figli tutti i file descriptor aperti nel
padre (allo stesso modo in cui lo fa la funzione \func{dup}, trattata in
sez.~\ref{sec:file_dup}), il che comporta che padre e figli condividono le
-stesse voci della \textit{file table} (per la spiegazione di questi termini si
-veda sez.~\ref{sec:file_sharing}) fra cui c'è anche la posizione corrente nel
-file.
+stesse voci della \itindex{file~table} \textit{file table} (per la spiegazione
+di questi termini si veda sez.~\ref{sec:file_sharing}) fra cui c'è anche la
+posizione corrente nel file.
In questo modo se un processo scrive sul file aggiornerà la posizione corrente
-sulla \textit{file table}, e tutti gli altri processi, che vedono la stessa
-\textit{file table}, vedranno il nuovo valore. In questo modo si evita, in
-casi come quello appena mostrato in cui diversi processi scrivono sullo stesso
-file, che l'output successivo di un processo vada a sovrapporsi a quello dei
-precedenti: l'output potrà risultare mescolato, ma non ci saranno parti
-perdute per via di una sovrascrittura.
+sulla \itindex{file~table} \textit{file table}, e tutti gli altri processi,
+che vedono la stessa \itindex{file~table} \textit{file table}, vedranno il
+nuovo valore. In questo modo si evita, in casi come quello appena mostrato in
+cui diversi processi scrivono sullo stesso file, che l'output successivo di un
+processo vada a sovrapporsi a quello dei precedenti: l'output potrà risultare
+mescolato, ma non ci saranno parti perdute per via di una sovrascrittura.
Questo tipo di comportamento è essenziale in tutti quei casi in cui il padre
crea un figlio e attende la sua conclusione per proseguire, ed entrambi
proprietà; la lista dettagliata delle proprietà che padre e figlio hanno in
comune dopo l'esecuzione di una \func{fork} è la seguente:
\begin{itemize*}
-\item i file aperti e gli eventuali flag di
- \textit{close-on-exec}\itindex{close-on-exec} impostati (vedi
- sez.~\ref{sec:proc_exec} e sez.~\ref{sec:file_fcntl});
+\item i file aperti e gli eventuali flag di \itindex{close-on-exec}
+ \textit{close-on-exec} impostati (vedi sez.~\ref{sec:proc_exec} e
+ sez.~\ref{sec:file_fcntl});
\item gli identificatori per il controllo di accesso: l'\textsl{user-ID
reale}, il \textsl{group-ID reale}, l'\textsl{user-ID effettivo}, il
\textsl{group-ID effettivo} ed i \textit{group-ID supplementari} (vedi
sez.~\ref{sec:proc_access_id});
-\item gli identificatori per il controllo di sessione: il \textit{process
- group-ID} e il \textit{session id} ed il terminale di controllo (vedi
- sez.~\ref{sec:sess_proc_group});
+\item gli identificatori per il controllo di sessione: il
+ \itindex{process~group} \textit{process group-ID} e il \textit{session id}
+ ed il terminale di controllo (vedi sez.~\ref{sec:sess_proc_group});
\item la directory di lavoro e la directory radice (vedi
sez.~\ref{sec:file_work_dir} e sez.~\ref{sec:file_chroot});
-\item la maschera dei permessi di creazione (vedi sez.~\ref{sec:file_umask});
+\item la maschera dei permessi di creazione (vedi
+ sez.~\ref{sec:file_perm_managemen});
\item la maschera dei segnali bloccati (vedi sez.~\ref{sec:sig_sigmask}) e le
azioni installate (vedi sez.~\ref{sec:sig_gen_beha});
\item i segmenti di memoria condivisa agganciati al processo (vedi
\func{fork} veniva fatta solo per poi eseguire una \func{exec}. La funzione
venne introdotta in BSD per migliorare le prestazioni.
-Dato che Linux supporta il \textit{copy on write}\itindex{copy~on~write} la
+Dato che Linux supporta il \itindex{copy~on~write} \textit{copy on write} la
perdita di prestazioni è assolutamente trascurabile, e l'uso di questa
funzione (che resta un caso speciale della system call \func{\_\_clone}) è
deprecato; per questo eviteremo di trattarla ulteriormente.
dal processo (vedi sez.~\ref{sec:sys_unix_time}) e lo stato di terminazione,
mentre la memoria in uso ed i file aperti vengono rilasciati immediatamente. I
processi che sono terminati, ma il cui stato di terminazione non è stato
-ancora ricevuto dal padre sono chiamati \textit{zombie}\index{zombie}, essi
+ancora ricevuto dal padre sono chiamati \index{zombie} \textit{zombie}, essi
restano presenti nella tabella dei processi ed in genere possono essere
identificati dall'output di \cmd{ps} per la presenza di una \texttt{Z} nella
colonna che ne indica lo stato (vedi tab.~\ref{tab:proc_proc_states}). Quando
\end{verbatim} %$
\normalsize e come si vede, dato che non si è fatto nulla per riceverne lo
stato di terminazione, i tre processi figli sono ancora presenti pur essendosi
-conclusi, con lo stato di zombie\index{zombie} e l'indicazione che sono stati
-terminati.
-
-La possibilità di avere degli zombie\index{zombie} deve essere tenuta sempre
-presente quando si scrive un programma che deve essere mantenuto in esecuzione
-a lungo e creare molti figli. In questo caso si deve sempre avere cura di far
-leggere l'eventuale stato di uscita di tutti i figli (in genere questo si fa
-attraverso un apposito \textit{signal handler}, che chiama la funzione
-\func{wait}, vedi sez.~\ref{sec:sig_sigchld} e sez.~\ref{sec:proc_wait}).
-Questa operazione è necessaria perché anche se gli
-\textit{zombie}\index{zombie} non consumano risorse di memoria o processore,
+conclusi, con lo stato di \index{zombie} \textit{zombie} e l'indicazione che
+sono stati terminati.
+
+La possibilità di avere degli \index{zombie} \textit{zombie} deve essere
+tenuta sempre presente quando si scrive un programma che deve essere mantenuto
+in esecuzione a lungo e creare molti figli. In questo caso si deve sempre
+avere cura di far leggere l'eventuale stato di uscita di tutti i figli (in
+genere questo si fa attraverso un apposito \textit{signal handler}, che chiama
+la funzione \func{wait}, vedi sez.~\ref{sec:sig_sigchld} e
+sez.~\ref{sec:proc_wait}). Questa operazione è necessaria perché anche se gli
+\index{zombie} \textit{zombie} non consumano risorse di memoria o processore,
occupano comunque una voce nella tabella dei processi, che a lungo andare
potrebbe esaurirsi.
Si noti che quando un processo adottato da \cmd{init} termina, esso non
-diviene uno \textit{zombie}\index{zombie}; questo perché una delle funzioni di
-\cmd{init} è appunto quella di chiamare la funzione \func{wait} per i processi
-cui fa da padre, completandone la terminazione. Questo è quanto avviene anche
-quando, come nel caso del precedente esempio con \cmd{forktest}, il padre
-termina con dei figli in stato di zombie\index{zombie}: alla sua terminazione
-infatti tutti i suoi figli (compresi gli zombie\index{zombie}) verranno
-adottati da \cmd{init}, il quale provvederà a completarne la terminazione.
-
-Si tenga presente infine che siccome gli zombie\index{zombie} sono processi
-già usciti, non c'è modo di eliminarli con il comando \cmd{kill}; l'unica
-possibilità di cancellarli dalla tabella dei processi è quella di terminare il
-processo che li ha generati, in modo che \cmd{init} possa adottarli e
-provvedere a concluderne la terminazione.
-
-
-\subsection{Le funzioni \func{wait} e \func{waitpid}}
+diviene uno \index{zombie} \textit{zombie}; questo perché una delle funzioni
+di \cmd{init} è appunto quella di chiamare la funzione \func{wait} per i
+processi cui fa da padre, completandone la terminazione. Questo è quanto
+avviene anche quando, come nel caso del precedente esempio con \cmd{forktest},
+il padre termina con dei figli in stato di \index{zombie} \textit{zombie}:
+alla sua terminazione infatti tutti i suoi figli (compresi gli \index{zombie}
+\textit{zombie}) verranno adottati da \cmd{init}, il quale provvederà a
+completarne la terminazione.
+
+Si tenga presente infine che siccome gli \index{zombie} \textit{zombie} sono
+processi già usciti, non c'è modo di eliminarli con il comando \cmd{kill};
+l'unica possibilità di cancellarli dalla tabella dei processi è quella di
+terminare il processo che li ha generati, in modo che \cmd{init} possa
+adottarli e provvedere a concluderne la terminazione.
+
+
+\subsection{Le funzioni \func{wait} e \func{waitpid}}
\label{sec:proc_wait}
Uno degli usi più comuni delle capacità multitasking di un sistema unix-like
principale attende le richieste che vengono poi soddisfatte da una serie di
processi figli. Si è già sottolineato al paragrafo precedente come in questo
caso diventi necessario gestire esplicitamente la conclusione dei figli onde
-evitare di riempire di \textit{zombie}\index{zombie} la tabella dei processi;
+evitare di riempire di \index{zombie} \textit{zombie} la tabella dei processi;
le funzioni deputate a questo compito sono sostanzialmente due, \funcd{wait} e
\func{waitpid}. La prima, il cui prototipo è:
\begin{functions}
In genere in un programma non si vuole essere forzati ad attendere la
conclusione di un processo per proseguire, specie se tutto questo serve solo
-per leggerne lo stato di chiusura (ed evitare la presenza di
-\textit{zombie}\index{zombie}), per questo la modalità più usata per chiamare
-queste funzioni è quella di utilizzarle all'interno di un \textit{signal
- handler} (vedremo un esempio di come gestire \const{SIGCHLD} con i segnali
-in sez.~\ref{sec:sig_example}). In questo caso infatti, dato che il segnale è
+per leggerne lo stato di chiusura (ed evitare la presenza di \index{zombie}
+\textit{zombie}), per questo la modalità più usata per chiamare queste
+funzioni è quella di utilizzarle all'interno di un \textit{signal handler}
+(vedremo un esempio di come gestire \const{SIGCHLD} con i segnali in
+sez.~\ref{sec:sig_example}). In questo caso infatti, dato che il segnale è
generato dalla terminazione di un figlio, avremo la certezza che la chiamata a
\func{wait} non si bloccherà.
valutata solo se \val{WIFSIGNALED} ha restituito
un valore non nullo.\\
\macro{WCOREDUMP(s)} & Vera se il processo terminato ha generato un
- file di \itindex{core~dump}\textit{core
+ file di \itindex{core~dump} \textit{core
dump}. Può essere valutata solo se
\val{WIFSIGNALED} ha restituito un valore non
nullo.\footnotemark \\
bit (in genere 8) sono riservati per memorizzare lo stato di uscita, e altri
per indicare il segnale che ha causato la terminazione (in caso di
conclusione anomala), uno per indicare se è stato generato un
-\itindex{core~dump}\textit{core dump}, ecc.\footnote{le definizioni esatte
+\itindex{core~dump} \textit{core dump}, ecc.\footnote{le definizioni esatte
si possono trovare in \file{<bits/waitstatus.h>} ma questo file non deve
mai essere usato direttamente, esso viene incluso attraverso
\file{<sys/wait.h>}.}
processo chiama una di queste funzioni esso viene completamente sostituito dal
nuovo programma; il \acr{pid} del processo non cambia, dato che non viene
creato un nuovo processo, la funzione semplicemente rimpiazza lo
-\itindex{stack} stack, lo \itindex{heap} heap, i dati ed il testo del processo
+\itindex{stack} \textit{stack}, lo \itindex{heap} \textit{heap}, i
+\index{segmento!dati} dati ed il \index{segmento!testo} testo del processo
corrente con un nuovo programma letto da disco.
Ci sono sei diverse versioni di \func{exec} (per questo la si è chiamata
Le altre quattro funzioni si limitano invece a cercare di eseguire il file
indicato dall'argomento \param{path}, che viene interpretato come il
-\itindex{pathname}\textit{pathname} del programma.
+\itindex{pathname} \textit{pathname} del programma.
\begin{figure}[htb]
\centering
\item la directory radice e la directory di lavoro corrente (vedi
sez.~\ref{sec:file_work_dir});
\item la maschera di creazione dei file (\var{umask}, vedi
- sez.~\ref{sec:file_umask}) ed i \textit{lock} sui file (vedi
+ sez.~\ref{sec:file_perm_management}) ed i \textit{lock} sui file (vedi
sez.~\ref{sec:file_locking});
\item i segnali sospesi (\textit{pending}) e la maschera dei segnali (si veda
sez.~\ref{sec:sig_sigmask});
sez.~\ref{sec:sig_gen_beha}).
La gestione dei file aperti dipende dal valore che ha il flag di
-\textit{close-on-exec}\itindex{close-on-exec} (vedi anche
+\itindex{close-on-exec} \textit{close-on-exec} (vedi anche
sez.~\ref{sec:file_fcntl}) per ciascun file descriptor. I file per cui è
impostato vengono chiusi, tutti gli altri file restano aperti. Questo
significa che il comportamento predefinito è che i file restano aperti
Per le directory, lo standard POSIX.1 richiede che esse vengano chiuse
attraverso una \func{exec}, in genere questo è fatto dalla funzione
\func{opendir} (vedi sez.~\ref{sec:file_dir_read}) che effettua da sola
-l'impostazione del flag di \textit{close-on-exec}\itindex{close-on-exec} sulle
-directory che apre, in maniera trasparente all'utente.
+l'impostazione del flag di \itindex{close-on-exec} \textit{close-on-exec}
+sulle directory che apre, in maniera trasparente all'utente.
Abbiamo detto che l'\textsl{user-ID reale} ed il \textsl{group-ID reale}
restano gli stessi all'esecuzione di \func{exec}; lo stesso vale per
l'\textsl{user-ID effettivo} ed il \textsl{group-ID effettivo} (il significato
di questi identificatori è trattato in sez.~\ref{sec:proc_access_id}), tranne
-quando il file che si va ad eseguire abbia o il \itindex{suid~bit}\acr{suid}
+quando il file che si va ad eseguire abbia o il \itindex{suid~bit} \acr{suid}
bit o lo \itindex{sgid~bit} \acr{sgid} bit impostato, in questo caso
l'\textsl{user-ID effettivo} ed il \textsl{group-ID effettivo} vengono
impostati rispettivamente all'utente o al gruppo cui il file appartiene (per i
del programma per caricare le librerie necessarie ed effettuare il link
dell'eseguibile. Se il programma è in formato ELF per caricare le librerie
dinamiche viene usato l'interprete indicato nel segmento \const{PT\_INTERP},
-in genere questo è \file{/lib/ld-linux.so.1} per programmi linkati con le
-\acr{libc5}, e \file{/lib/ld-linux.so.2} per programmi linkati con le
+in genere questo è \file{/lib/ld-linux.so.1} per programmi collegati con le
+\acr{libc5}, e \file{/lib/ld-linux.so.2} per programmi collegati con le
\acr{glibc}.
Infine nel caso il file sia uno script esso deve iniziare con una linea nella
deve essere un programma valido (binario, non un altro script) che verrà
chiamato come se si fosse eseguito il comando \cmd{interpreter [argomenti]
filename}.\footnote{si tenga presente che con Linux quanto viene scritto
- come \texttt{argomenti} viene passato all'inteprete come un unico argomento
+ come \texttt{argomenti} viene passato all'interprete come un unico argomento
con una unica stringa di lunghezza massima di 127 caratteri e se questa
dimensione viene ecceduta la stringa viene troncata; altri Unix hanno
dimensioni massime diverse, e diversi comportamenti, ad esempio FreeBSD
esegue la scansione della riga e la divide nei vari argomenti e se è troppo
- lunga restitituisce un errore di \const{ENAMETOOLONG}, una comparazione dei
+ lunga restituisce un errore di \const{ENAMETOOLONG}, una comparazione dei
vari comportamenti si trova su
\href{http://www.in-ulm.de/~mascheck/various/shebang/}
{\texttt{http://www.in-ulm.de/\tild mascheck/various/shebang/}}.}
realtà già esistono estensioni di questo modello base, che lo rendono più
flessibile e controllabile, come le \itindex{capabilities}
\textit{capabilities} illustrate in sez.~\ref{sec:proc_capabilities}, le ACL
- per i file o il \textit{Mandatory Access Control}
- \itindex{Mandatory~Access~Control~(MAC)} di SELinux; inoltre basandosi sul
- lavoro effettuato con SELinux, a partire dal kernel 2.5.x, è iniziato lo
- sviluppo di una infrastruttura di sicurezza, il \textit{Linux Security
- Modules}, o LSM, in grado di fornire diversi agganci a livello del kernel
- per modularizzare tutti i possibili controlli di accesso.} di sicurezza di
-un sistema unix-like è fondato sui concetti di utente e gruppo, e sulla
-separazione fra l'amministratore (\textsl{root}, detto spesso anche
-\textit{superuser}) che non è sottoposto a restrizioni, ed il resto degli
-utenti, per i quali invece vengono effettuati i vari controlli di accesso.
+ per i file o il \itindex{Mandatory~Access~Control~(MAC)} \textit{Mandatory
+ Access Control} di SELinux; inoltre basandosi sul lavoro effettuato con
+ SELinux, a partire dal kernel 2.5.x, è iniziato lo sviluppo di una
+ infrastruttura di sicurezza, il \textit{Linux Security Modules}, o LSM, in
+ grado di fornire diversi agganci a livello del kernel per modularizzare
+ tutti i possibili controlli di accesso.} di sicurezza di un sistema
+unix-like è fondato sui concetti di utente e gruppo, e sulla separazione fra
+l'amministratore (\textsl{root}, detto spesso anche \textit{superuser}) che
+non è sottoposto a restrizioni, ed il resto degli utenti, per i quali invece
+vengono effettuati i vari controlli di accesso.
Abbiamo già accennato come il sistema associ ad ogni utente e gruppo due
identificatori univoci, lo user-ID ed il group-ID; questi servono al kernel per
sez.~\ref{sec:proc_exec}, il programma che si è posto in esecuzione abbia i
bit \itindex{suid~bit} \acr{suid} o \itindex{sgid~bit} \acr{sgid} impostati
(il significato di questi bit è affrontato in dettaglio in
-sez.~\ref{sec:file_suid_sgid}). In questo caso essi saranno impostati
+sez.~\ref{sec:file_special_perm}). In questo caso essi saranno impostati
all'utente e al gruppo proprietari del file. Questo consente, per programmi in
cui ci sia necessità, di dare a qualunque utente normale privilegi o permessi
di un altro (o dell'amministratore).
padre, e vengono impostati dalla funzione \func{exec} all'avvio del processo,
come copie dell'\textsl{user-ID effettivo} e del \textsl{group-ID effettivo}
dopo che questi sono stati impostati tenendo conto di eventuali
-\itindex{suid~bit}\acr{suid} o \itindex{sgid~bit} \acr{sgid}. Essi quindi
+\itindex{suid~bit} \acr{suid} o \itindex{sgid~bit} \acr{sgid}. Essi quindi
consentono di tenere traccia di quale fossero utente e gruppo effettivi
all'inizio dell'esecuzione di un nuovo programma.
Come accennato l'uso principale di queste funzioni è quello di poter
consentire ad un programma con i bit \itindex{suid~bit} \acr{suid} o
-\itindex{sgid~bit} \acr{sgid} impostati (vedi sez.~\ref{sec:file_suid_sgid})
+\itindex{sgid~bit} \acr{sgid} impostati (vedi sez.~\ref{sec:file_special_perm})
di riportare l'\textsl{user-ID effettivo} a quello dell'utente che ha lanciato
il programma, effettuare il lavoro che non necessita di privilegi aggiuntivi,
ed eventualmente tornare indietro.
ricorrere ad altre funzioni.
Le due funzioni \funcd{setreuid} e \funcd{setregid} derivano da BSD che, non
-supportando\footnote{almeno fino alla versione 4.3+BSD TODO, FIXME verificare
- e aggiornare la nota.} gli identificatori del gruppo \textit{saved}, le usa
-per poter scambiare fra di loro \textit{effective} e \textit{real}. I
-rispettivi prototipi sono:
+supportando\footnote{almeno fino alla versione 4.3+BSD.} gli identificatori
+del gruppo \textit{saved}, le usa per poter scambiare fra di loro
+\textit{effective} e \textit{real}. I rispettivi prototipi sono:
\begin{functions}
\headdecl{unistd.h}
\headdecl{sys/types.h}
Anche queste funzioni sono un'estensione specifica di Linux, e non richiedono
nessun privilegio. I valori sono restituiti negli argomenti, che vanno
specificati come puntatori (è un altro esempio di
-\itindex{value~result~argument}\textit{value result argument}). Si noti che
+\itindex{value~result~argument} \textit{value result argument}). Si noti che
queste funzioni sono le uniche in grado di leggere gli identificatori del
gruppo \textit{saved}.
\subsection{La gestione delle \textit{capabilities}}
\label{sec:proc_capabilities}
-
\itindbeg{capabilities}
Come accennato in sez.~\ref{sec:proc_access_id} l'architettura classica della
\textbf{Capacità}&\textbf{Descrizione}\\
\hline
\hline
+%
+% POSIX-draft defined capabilities.
+%
\const{CAP\_CHOWN} & la capacità di cambiare proprietario e gruppo
proprietario di un file (vedi
- sez.~\ref{sec:file_chown}).\\
+ sez.~\ref{sec:file_ownership_management}).\\
\const{CAP\_DAC\_OVERRIDE}& la capacità di evitare il controllo dei
permessi di lettura, scrittura ed esecuzione dei
file, (vedi sez.~\ref{sec:file_access_control})
precedenti \const{CAP\_DAC\_OVERRIDE} e
\const{CAP\_DAC\_READ\_SEARCH}. Queste
comprendono i cambiamenti dei permessi e dei
- tempi del file (vedi sez.~\ref{sec:file_chmod} e
- sez.~\ref{sec:file_utime}), le impostazioni degli
- attributi estesi (con il comando \cmd{chattr}) e
- delle ACL, poter ignorare lo
+ tempi del file (vedi
+ sez.~\ref{sec:file_perm_management} e
+ sez.~\ref{sec:file_file_times}), le impostazioni
+ degli attributi estesi (con il comando
+ \cmd{chattr}) e delle ACL, poter ignorare lo
\itindex{sticky~bit} \textit{sticky bit} nella
cancellazione dei file (vedi
- sez.~\ref{sec:file_sticky}), la possibilità di
- impostare il flag di \const{O\_NOATIME} con
+ sez.~\ref{sec:file_special_perm}), la possibilità
+ di impostare il flag di \const{O\_NOATIME} con
\func{open} e \func{fcntl} (vedi
sez.~\ref{sec:file_open} e
sez.~\ref{sec:file_fcntl}).\\
un processo senza questa capacità e la capacità
di impostare il bit \acr{sgid} su un file anche
quando questo è relativo ad un gruppo cui non si
- appartiene (vedi sez.~\ref{sec:file_chmod}).\\
- \const{CAP\_IPC\_LOCK} & la capacità di effettuare il \textit{memory
- locking} \itindex{memory~locking} con le
- funzioni \func{mlock}, \func{mlockall},
- \func{shmctl}, \func{mmap} (vedi
- sez.~\ref{sec:proc_mem_lock} e
- sez.~\ref{sec:file_memory_map}). \\
- \const{CAP\_IPC\_OWNER} & la capacità di evitare il controllo dei permessi
- per le operazioni sugli oggetti di
- intercomunicazione fra processi (vedi
- sez.~\ref{sec:ipc_sysv}).\\
+ appartiene (vedi
+ sez.~\ref{sec:file_perm_management}).\\
\const{CAP\_KILL} & la capacità di mandare segnali a qualunque
processo (vedi sez.~\ref{sec:sig_kill_raise}).\\
- \const{CAP\_LEASE} & la capacità di creare dei \textit{file lease}
- \index{file!lease} su di un file (vedi
- sez.~\ref{sec:file_asyncronous_lease})
- indipendentemente dalla proprietà dello
- stesso.\footnotemark\\
+ \const{CAP\_SETGID} & la capacità di manipolare i group ID dei
+ processi, sia il principale che i supplementari,
+ (vedi sez.~\ref{sec:proc_setgroups} che quelli
+ trasmessi tramite i socket \textit{unix domain}
+ (vedi sez.~\ref{sec:unix_socket}).\\
+ \const{CAP\_SETUID} & la capacità di manipolare gli user ID del
+ processo (con \func{setuid}, \func{setreuid},
+ \func{setresuid}, \func{setfsuid}) e di
+ trasmettere un valore arbitrario
+ dell'\textsl{uid} nel passaggio delle
+ credenziali coi socket \textit{unix domain} (vedi
+ sez.~\ref{sec:unix_socket}).\\
+%
+% Linux specific capabilities
+%
+\hline
+ \const{CAP\_SETPCAP} & la capacità di impostare o rimuovere una capacità
+ (limitatamente a quelle che il processo
+ chiamante ha nel suo insieme di capacità
+ permesse) da qualunque processo.\\
\const{CAP\_LINUX\_IMMUTABLE}& la capacità di impostare gli attributi
- \textit{immutable} e \textit{append only} per i
- file su un filesystem che supporta questi
+ \textit{immutable} e \itindex{append~mode}
+ \textit{append only} per i file su un
+ filesystem che supporta questi
attributi estesi.\\
- \const{CAP\_MKNOD} & la capacità di creare file di dispositivo con la
- funzione \func{mknod} (vedi
- sez.~\ref{sec:file_mknod}).\footnotemark\\
- \const{CAP\_NET\_ADMIN} & la capacità di eseguire alcune operazioni
- privilegiate sulla rete (impostare le opzioni
- privilegiate dei socket, abilitare il
- multicasting, impostare interfacce di rete e
- tabella di instradamento).\\
\const{CAP\_NET\_BIND\_SERVICE}& la capacità di porre in ascolto server
su porte riservate (vedi
sez.~\ref{sec:TCP_func_bind}).\\
\const{CAP\_NET\_BROADCAST}& la capacità di consentire l'uso di socket in
- broadcast e multicast.\\
+ \itindex{broadcast} \textit{broadcast} e
+ \itindex{multicast} \textit{multicast}.\\
+ \const{CAP\_NET\_ADMIN} & la capacità di eseguire alcune operazioni
+ privilegiate sulla rete (impostare le opzioni
+ privilegiate dei socket, abilitare il
+ \itindex{multicast} \textit{multicasting},
+ impostare interfacce di rete e
+ tabella di instradamento).\\
\const{CAP\_NET\_RAW} & la capacità di usare socket \texttt{RAW} e
\texttt{PACKET} (quelli che permettono di creare
pacchetti nei protocolli di basso livello).\\
- \const{CAP\_SETGID} & la capacità di manipolare i group ID dei
- processi, sia il principale che i supplementari,
- (vedi sez.~\ref{sec:proc_setgroups} che quelli
- trasmessi tramite i \index{socket} socket
- \textit{unix domain} (vedi
- sez.~\ref{sec:unix_socket}).\\
- \const{CAP\_SETPCAP} & la capacità di impostare o rimuovere una capacità
- (limitatamente a quelle che il processo
- chiamante ha nel suo insieme di capacità
- permesse) da qualunque processo.\\
- \const{CAP\_SETUID} & la capacità di manipolare gli user ID del
- processo (con \func{setuid}, \func{setreuid},
- \func{setresuid}, \func{setfsuid}) e di
- trasmettere un valore arbitrario
- dell'\textsl{uid} nel passaggio delle
- credenziali coi socket unix domain (vedi
- sez.~\ref{sec:unix_socket_xxx}).\\
+ \const{CAP\_IPC\_LOCK} & la capacità di effettuare il \textit{memory
+ locking} \itindex{memory~locking} con le
+ funzioni \func{mlock}, \func{mlockall},
+ \func{shmctl}, \func{mmap} (vedi
+ sez.~\ref{sec:proc_mem_lock} e
+ sez.~\ref{sec:file_memory_map}). \\
+ \const{CAP\_IPC\_OWNER} & la capacità di evitare il controllo dei permessi
+ per le operazioni sugli oggetti di
+ intercomunicazione fra processi (vedi
+ sez.~\ref{sec:ipc_sysv}).\\
+ \const{CAP\_SYS\_MODULE}& la capacità di caricare e rimuovere moduli del
+ kernel. \\
+ \const{CAP\_SYS\_RAWIO} & la capacità di eseguire operazioni sulle porte
+ di I/O con \func{ioperm} e \func{iopl} (vedi
+ sez.~\ref{sec:file_io_port}).\\
+ \const{CAP\_SYS\_CHROOT}& la capacità di eseguire la funzione
+ \func{chroot} (vedi
+ sez.~\ref{sec:file_chroot}).\\
+ \const{CAP\_SYS\_PTRACE}& consente di tracciare qualunque processo con
+ \func{ptrace} (vedi
+ sez.~\ref{sec:xxx_ptrace}).\\
+% TODO documentatare ptrace
+ \const{CAP\_SYS\_PACCT} & la capacità di usare le funzioni di
+ \textit{accounting} dei processi (vedi
+ sez.~\ref{sec:sys_bsd_accounting}).\\
\const{CAP\_SYS\_ADMIN} & la capacità di eseguire una serie di compiti
amministrativi (come impostare le quote,
attivare e disattivare la swap, montare,
rimontare e smontare filesystem, ecc.). \\
- \const{CAP\_SYS\_BOOT} & la capacità di fare eseguire un reboot del
+ \const{CAP\_SYS\_BOOT} & la capacità di fare eseguire un riavvio del
sistema.\\
- \const{CAP\_SYS\_CHROOT}& la capacità di eseguire la funzione
- \func{chroot} (vedi
- sez.~\ref{sec:file_chroot}).\\
- \const{CAP\_SYS\_MODULE}& la capacità di caricare e rimuovere moduli del
- kernel. \\
\const{CAP\_SYS\_NICE} & la capacità di modificare le priorità dei
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}).\\
- \const{CAP\_SYS\_RAWIO} & la capacità di eseguire operazioni sulle porte
- di I/O con \func{ioperm} e \func{iopl} (vedi
- sez.~\ref{sec:file_io_port}).\\
\const{CAP\_SYS\_RESOURCE}& la capacità di superare le limitazioni sulle
risorse, aumentare le quote disco, usare lo
spazio disco riservato all'amministratore.\\
\const{CAP\_SYS\_TTY\_CONFIG}& la capacità di simulare un \textit{hangup}
della console, con la funzione
\func{vhangup}.\\
- \const{CAP\_SYS\_PTRACE}& consente di tracciare qualunque processo con
- \func{ptrace} (vedi
- sez.~\ref{sec:xxx_ptrace}).\\
-% TODO documentatare ptrace
+ \const{CAP\_MKNOD} & la capacità di creare file di dispositivo con la
+ funzione \func{mknod} (vedi
+ sez.~\ref{sec:file_mknod}).\footnotemark\\
+ \const{CAP\_LEASE} & la capacità di creare dei \textit{file lease}
+ \index{file!lease} su di un file (vedi
+ sez.~\ref{sec:file_asyncronous_lease})
+ indipendentemente dalla proprietà dello
+ stesso.\footnotemark\\
+ \const{CAP\_SETFCAP} & la capacità di impostare le
+ \textit{capabilities} di un file (non
+ supportata).\\
\hline
\end{tabular}
\caption{Le costanti che identificano le \textit{capabilities} presenti nel
\label{tab:proc_capabilities}
\end{table}
-\footnotetext[18]{questa capacità è presente soltato a partire dai kernel
+\footnotetext[21]{questa capacità è presente soltanto a partire dai kernel
della serie 2.4.x.}
-\footnotetext{questa capacità è presente soltato a partire dai kernel della
+\footnotetext{questa capacità è presente soltanto a partire dai kernel della
serie 2.4.x.}
Per gestire questo nuovo meccanismo ciascun processo porta con sé tre distinti
all'interno della \struct{task\_struct} di ciascun processo (vedi
fig.~\ref{fig:proc_task_struct}), nei tre campi \texttt{cap\_effective},
\texttt{cap\_inheritable}, \texttt{cap\_permitted} del tipo
- \texttt{kernel\_cap\_t} (definito come intero a 32 bit), il che comporta un
- massimo di 32 \textit{capabilities} distinte.} in cui ciascun bit
-corrisponde ad una capacità diversa; se ne è riportato l'elenco,\footnote{si
- tenga presente che l'elenco delle \textit{capabilities} presentato questa
- tabella, ripreso dalla relativa pagina di manuale (accessibile con
- \texttt{man capabilities}), è quello aggiornato al kernel 2.6.6.} con una
+ \texttt{kernel\_cap\_t}; questo è attualmente definito come intero a 32 bit,
+ il che comporta un massimo di 32 \textit{capabilities} distinte.} in cui
+ciascun bit corrisponde ad una capacità diversa; se ne è riportato
+l'elenco,\footnote{si tenga presente che l'elenco delle \textit{capabilities}
+ presentato questa tabella, ripreso dalla relativa pagina di manuale
+ (accessibile con \texttt{man capabilities}) e dalle definizioni in
+ \texttt{sys/capabilities.h}, è quello aggiornato al kernel 2.6.6.} con una
breve descrizione, ed il nome delle costanti che identificano i singoli bit,
-in tab.~\ref{tab:proc_capabilities}.
+in tab.~\ref{tab:proc_capabilities}; la tabella è divisa in due parti, la
+prima riporta le \textit{capabilities} previste nella bozza dello standard
+POSIX1.e, la seconda quelle specifiche di Linux.
L'utilizzo di tre distinti insiemi serve a fornire una interfaccia flessibile
per l'uso delle \textit{capabilities}, con scopi analoghi a quelli per cui
sez.~\ref{sec:proc_setuid}; il loro significato è il seguente:
\begin{basedescript}{\desclabelwidth{2.0cm}\desclabelstyle{\nextlinelabel}}
\item[\textit{effective}] l'insieme delle \textit{capabilities}
- ``\textsl{effettive}'', cioè quelle che vengono effettivamente usate dal
- kernel per eseguire il controllo di accesso per le operazioni compiute dal
- processo.
+ ``\textsl{effettive}'', cioè di quelle che vengono effettivamente usate dal
+ kernel quando deve eseguire il controllo di accesso per le varie operazioni
+ compiute dal processo.
\item[\textit{permitted}] l'insieme delle \textit{capabilities}
- ``\textsl{permesse}'', cioè l'insieme di quelle che un processo \textsl{può}
- impostare come \textsl{effettive} se ha la capacità \const{CAP\_SETPCAP}. Se
- un processo cancella una capacità da questo insieme non potrà più
- riassumerla (almeno che non esegua un programma che è \acr{suid} di root).
+ ``\textsl{permesse}'', cioè l'insieme di quelle capacità che un processo
+ \textsl{può} impostare come \textsl{effettive}. Se un processo cancella una
+ capacità da questo insieme non potrà più riassumerla (almeno che non esegua
+ un programma che è \acr{suid} di root).
\item[\textit{inherited}] l'insieme delle \textit{capabilities}
- \textsl{ereditate}, cioè quelle che vengono trasmesse ad un nuovo programma
- eseguito attraverso una chiamata ad \func{exec} (con l'eccezione del caso
- che questo sia \acr{suid} di root).
+ ``\textsl{ereditabili}'', cioè quelle che vengono trasmesse ad un nuovo
+ programma eseguito attraverso una chiamata ad \func{exec} (con l'eccezione
+ del caso che questo sia \acr{suid} di root).
+\label{sec:capabilities_set}
\end{basedescript}
-
Oltre a questi tre insiemi, che sono relativi al singolo processo, il kernel
mantiene un insieme generale valido per tutto il sistema, chiamato
-\index{capabilities~bounding~set} \textit{capabilities bounding set}. Ogni
+\itindex{capabilities~bounding~set} \textit{capabilities bounding set}. Ogni
volta che un programma viene posto in esecuzione con \func{exec} il contenuto
degli insiemi \textit{effective} e \textit{permitted} vengono mascherati con
un \textsl{AND} binario del contenuto corrente del \textit{capabilities
essere impostato ad un valore arbitrario esclusivamente dal primo processo
eseguito nel sistema (di norma cioè da \texttt{/sbin/init}), ogni processo
eseguito successivamente (cioè con \textsl{pid} diverso da 1) anche se
-eseguito con privilegi di amministratore può al più rimuovere uno dei bit
-dell'insieme: questo significa che una volta rimossa da esso una
-\textit{capability} essa non sarà più disponibile, neanche per
-l'amministratore, a meno di un riavvio.
-
-
-Quando viene messo in esecuzione (con \func{exec}) un processo eredita le
-\textit{capabilities} mantenute nell'insieme \textit{inherited}, a meno che
+eseguito con privilegi di amministratore potrà soltanto rimuovere uno dei bit
+già presenti dell'insieme: questo significa che una volta rimossa una
+\textit{capability} dal \textit{capabilities bounding set} essa non sarà più
+disponibile, neanche per l'amministratore, a meno di un riavvio.
+
+Quando un programma viene messo in esecuzione\footnote{cioè quando viene
+ eseguita la \func{execve} con cui lo si lancia; in corrispondenza di una
+ \func{fork} le \textit{capabilities} non vengono modificate.} esso eredita
+(nel senso che assume negli insiemi \textit{effective} e \textit{permitted})
+le \textit{capabilities} mantenute nell'insieme \textit{inherited}, a meno che
non sia eseguito un programma \acr{suid} di root o la \func{exec} sia stata
eseguita da un programma con \textsl{uid} reale zero; in tal caso il programma
ottiene tutte le \textit{capabilities} presenti nel \textit{capabilities
- bounding set}.
+ bounding set}. In questo modo si può far si che ad un processo eseguito in
+un secondo tempo possano essere trasmesse solo un insieme limitato di
+capacità, impedendogli di recuperare quelle assenti nell'insieme
+\textit{inherited}. Si tenga presente invece che attraverso una \func{fork}
+vengono mantenute le stesse capacità del processo padre.
+
+Per la gestione delle \textit{capabilities} il kernel mette a disposizione due
+funzioni che permettono rispettivamente di leggere ed impostare i valori dei
+tre insiemi illustrati in precedenza. Queste due funzioni sono \funcd{capget}
+e \funcd{capset} e costituiscono l'interfaccia di gestione basso livello; i
+loro rispettivi prototipi sono:
+\begin{functions}
+ \headdecl{sys/capability.h}
+
+ \funcdecl{int capget(cap\_user\_header\_t hdrp, cap\_user\_data\_t datap)}
+ Legge le \textit{capabilities}.
+
+ \funcdecl{int capset(cap\_user\_header\_t hdrp, const cap\_user\_data\_t
+ datap)}
+ Imposta le \textit{capabilities}.
+
+
+ \bodydesc{Entrambe le funzioni ritornano 0 in caso di successo e -1 in caso
+ di errore, nel qual caso \var{errno} può assumere i valori:
+ \begin{errlist}
+ \item[\errcode{ESRCH}] si è fatto riferimento ad un processo inesistente.
+ \item[\errcode{EPERM}] si è tentato di aggiungere una capacità
+ nell'insieme delle \textit{capabilities} permesse, o di impostare una
+ capacità non presente nell'insieme di quelle permesse negli insieme
+ delle effettive o ereditate, o si è cercato di impostare una
+ \textit{capability} di un altro processo senza avare
+ \const{CAP\_SETPCAP}.
+ \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. Pertanto se si vogliono scrivere
+programmi portabili che possano essere eseguiti su qualunque versione del
+kernel è opportuno utilizzare le interfacce di alto livello.
+
+\begin{figure}[!htb]
+ \footnotesize
+ \centering
+ \begin{minipage}[c]{15cm}
+ \includestruct{listati/cap_user_header_t.h}
+ \end{minipage}
+ \normalsize
+ \caption{Definizione delle strutture a cui fanno riferimento i puntatori
+ \structd{cap\_user\_header\_t} e \structd{cap\_user\_data\_t} usati per
+ l'interfaccia di gestione di basso livello delle \textit{capabilities}.}
+ \label{fig:cap_kernel_struct}
+\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
+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.
+
+Dato che le precedenti funzioni, oltre ad essere specifiche di Linux, non
+garantiscono la stabilità nell'interfaccia, è sempre opportuno effettuare la
+gestione delle \textit{capabilities} utilizzando le funzioni di libreria a
+questo dedicate. Queste funzioni, che seguono quanto previsto nelle bozze
+dello standard POSIX.1e, non fanno parte delle \acr{glibc} e sono fornite in
+una libreria a parte,\footnote{la libreria è \texttt{libcap2}, nel caso di
+ Debian può essere installata con il pacchetto omonimo.} pertanto se un
+programma le utilizza si dovrà indicare esplicitamente l'uso della suddetta
+libreria attraverso l'opzione \texttt{-lcap} del compilatore.
+
+Le funzioni dell'interfaccia delle bozze di POSIX.1e prevedono l'uso di 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}.
+
+La prima funzione dell'interfaccia è quella che permette di inizializzare un
+\textit{capability state}, allocando al contempo la memoria necessaria per i
+relativi dati. La funzione è \funcd{cap\_init} ed il suo prototipo è:
+\begin{functions}
+ \headdecl{sys/capability.h}
+ \funcdecl{cap\_t cap\_init(void)}
+ 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
+ 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}
+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 la
+funzione \funcd{cap\_free}, il cui prototipo è:
+\begin{functions}
+ \headdecl{sys/capability.h}
+ \funcdecl{int cap\_free(void *obj\_d)}
+ Disalloca la memoria allocata per i dati delle \textit{capabilities}.
+
+ \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 permette di liberare la memoria allocata dalle altre funzioni
+della libreria sia per un \textit{capability state}, nel qual caso l'argomento
+dovrà essere un dato di tipo \type{cap\_t}, che per una descrizione testuale
+dello stesso,\footnote{cioè quanto ottenuto tramite la funzione
+ \func{cap\_to\_text}.} nel qual caso l'argomento dovrà essere di tipo
+\texttt{char *}. L'argomento \param{obj\_d} deve corrispondere ad un oggetto
+ottenuto tramite 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 è:
+\begin{functions}
+ \headdecl{sys/capability.h}
+ \funcdecl{cap\_t cap\_dup(cap\_t cap\_p)}
+ 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
+ valori \errval{ENOMEM} o \errval{EINVAL}.
+ }
+\end{functions}
+La funzione crea una copia del \textit{capability state} posto all'indirizzo
+\param{cap\_p} che si è passato come argomento, restituendo il puntatore alla
+copia, che conterrà gli stessi valori delle \textit{capabilities} presenti
+nell'originale. La memoria necessaria viene allocata automaticamente dalla
+funzione. Una volta effettuata la copia i due \textit{capability state}
+potranno essere modificati in maniera completamente indipendente.
+Una seconda classe di funzioni di servizio sono quelle per la gestione dei
+dati contenuti all'interno di un \textit{capability state}; la prima di esse è
+\funcd{cap\_clear}, il cui prototipo è:
+\begin{functions}
+ \headdecl{sys/capability.h}
+ \funcdecl{int cap\_clear(cap\_t cap\_p)}
+ Inizializza un \textit{capability state} cancellando tutte le
+ \textit{capabilities}.
+
+ \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 si limita ad azzerare tutte le \textit{capabilities} presenti nel
+\textit{capability state} all'indirizzo \param{cap\_p} passato come argomento,
+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,
+\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:
+\begin{functions}
+ \headdecl{sys/capability.h}
+ \funcdecl{int cap\_get\_flag(cap\_t cap\_p, cap\_value\_t cap, cap\_flag\_t
+ flag, cap\_flag\_value\_t *value\_p)}
+ Legge il valore di una \textit{capability}.
+ \funcdecl{int cap\_set\_flag(cap\_t cap\_p, cap\_flag\_t flag, int ncap,
+ cap\_value\_t *caps, cap\_flag\_value\_t value)}
+ Imposta il valore di una \textit{capability}.
+
+ \bodydesc{Le funzioni ritornano 0 in caso di successo e $-1$ in caso di
+ errore, nel qual caso \var{errno} assumerà il valore \errval{EINVAL}.
+}
+\end{functions}
+
+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
+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}.} Infine lo stato di una capacità è
+descritto ad una variabile di tipo \type{cap\_flag\_value\_t}, che a sua volta
+può assumere soltanto uno\footnote{anche questo è un tipo enumerato.} dei
+valori di tab.~\ref{tab:cap_value_type}.
+
+\begin{table}[htb]
+ \centering
+ \footnotesize
+ \begin{tabular}[c]{|l|l|}
+ \hline
+ \textbf{Valore} & \textbf{Significato} \\
+ \hline
+ \hline
+ \const{CAP\_CLEAR}& La capacità non è impostata.\\
+ \const{CAP\_SET} & La capacità è impostata.\\
+ \hline
+ \end{tabular}
+ \caption{Valori possibili per il tipo di dato \type{cap\_flag\_value\_t} che
+ indica lo stato di una capacità.}
+ \label{tab:cap_value_type}
+\end{table}
+
+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.
+
+La funzione \func{cap\_set\_flag} può invece impostare in una sola chiamata
+più capacità, anche se solo all'interno dello stesso insieme; per questo essa
+prende un vettore di valori di tipo \type{cap\_value\_t} nell'argomento
+\param{caps}, la cui dimensione è 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 è:
+\begin{functions}
+ \headdecl{sys/capability.h}
+
+ \funcdecl{char * cap\_to\_text(cap\_t caps, ssize\_t * length\_p)}
+
+ Genera una visualizzazione testuale delle \textit{capabilities}.
+
+ \bodydesc{La funzione ritorna un puntatore alla stringa con la descrizione
+ delle \textit{capabilities} 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 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 deve essere liberata con \func{cap\_free}.
+
+Fin quei abbiamo trattato delle funzioni di manipolazione dei
+\textit{capabilities state}; quando si vuole eseguire la lettura delle
+\textit{capabilities} del processo corrente si deve usare la funzione
+\funcd{cap\_get\_proc}, il cui prototipo è:
+\begin{functions}
+ \headdecl{sys/capability.h}
+
+ \funcdecl{cap\_t cap\_get\_proc(void)}
+ Legge le \textit{capabilities} del processo corrente.
+
+ \bodydesc{La funzione ritorna un valore diverso da \val{NULL} in caso di
+ successo e \val{NULL} in caso di errore, nel qual caso \var{errno} può
+ assumere i valori \errval{EINVAL}, \errval{EPERM} o \errval{ENOMEM}. }
+\end{functions}
+
+La funzione legge il valore delle \textit{capabilities} del processo corrente
+e restituisce il puntatore ad un \textit{capabilities state} contenente il
+risultato, che provvede ad allocare autonomamente, e che occorrerà liberare
+con \func{cap\_free} quando non sarà più utilizzato.
+
+Se invece si vogliono leggere le \textit{capabilities} di un processo
+specifico occorre usare la funzione \funcd{capgetp}, il cui
+prototipo\footnote{su alcune pagine di manuale la funzione è descritta con un
+ prototipo sbagliato, che prevede un valore di ritorno di tipo \type{cap\_t},
+ ma il valore di ritorno è intero, come si può verificare anche dalla
+ dichiarazione della stessa in \texttt{sys/capability.h}.} è:
+\begin{functions}
+ \headdecl{sys/capability.h}
+
+ \funcdecl{int capgetp(pid\_t pid, cap\_t cap\_d)}
+ Legge le \textit{capabilities} del processo indicato da \param{pid}.
+
+ \bodydesc{La funzione ritorna 0 in caso di successo e $-1$ in caso di
+ errore, nel qual caso \var{errno} può assumere i valori \errval{EINVAL},
+ \errval{EPERM} o \errval{ENOMEM}.
+ }
+\end{functions}
+
+La funzione legge il valore delle \textit{capabilities} del processo indicato
+con l'argomento \param{pid}, salvando il risultato nel \textit{capabilities
+ state} all'indirizzo \param{cap\_d} che deve essere stato creato in
+precedenza. Qualora il processo non esista si avrà un errore di
+\errval{ESRCH}. Gli stessi valori possono essere letti direttamente nel
+filesystem \textit{proc}, nei file \texttt{/proc/<pid>/status}; ad esempio per
+\texttt{init} si otterrà qualcosa del tipo:
+\begin{Verbatim}
+...
+CapInh: 0000000000000000
+CapPrm: 00000000fffffeff
+CapEff: 00000000fffffeff
+\end{Verbatim}
+
+Infine per impostare le \textit{capabilities} del processo corrente (non
+esiste una funzione che permetta di cambiare le \textit{capabilities} di un
+altro processo) si deve usare la funzione \funcd{cap\_set\_proc}, il cui
+prototipo è:
+\begin{functions}
+ \headdecl{sys/capability.h}
+
+ \funcdecl{int cap\_set\_proc(cap\_t cap\_p)}
+ Imposta le \textit{capabilities} del processo corrente.
+
+ \bodydesc{La funzione ritorna 0 in caso di successo e $-1$ in caso di
+ errore, nel qual caso \var{errno} può assumere i valori \errval{EINVAL},
+ \errval{EPERM} o \errval{ENOMEM}.
+ }
+\end{functions}
+
+La funzione modifica le \textit{capabilities} del processo corrente secondo
+quanto specificato con l'argomento \param{cap\_p}, posto che questo sia
+possibile nei termini spiegati in precedenza (non sarà ad esempio possibile
+impostare capacità non presenti nell'insieme di quelle permesse). In caso di
+successo i nuovi valori saranno effettivi al ritorno della funzione, in caso
+di fallimento invece lo stato delle capacità resterà invariato. Si tenga
+presente che \textsl{tutte} le capacità specificate tramite \param{cap\_p}
+devono essere permesse; se anche una sola non lo è la funzione fallirà, e per
+quanto appena detto, lo stato delle \textit{capabilities} non verrà modificato
+(neanche per le parti eventualmente permesse).
+
+Come esempio di utilizzo di queste funzioni nei sorgenti allegati alla guida
+si è distribuito il programma \texttt{getcap.c}, che consente di leggere le
+\textit{capabilities} del processo corrente\footnote{vale a dire di sé stesso,
+ quando lo si lancia, il che può sembrare inutile, ma serve a mostrarci quali
+ sono le \textit{capabilities} standard che ottiene un processo lanciato
+ dalla riga di comando.} o tramite l'opzione \texttt{-p}, quelle di un
+processo qualunque il cui pid viene passato come parametro dell'opzione.
+
+\begin{figure}[htb]
+ \footnotesize \centering
+ \begin{minipage}[c]{15cm}
+ \includecodesample{listati/getcap.c}
+ \end{minipage}
+ \normalsize
+ \caption{Corpo principale del programma \texttt{getcap.c}.}
+ \label{fig:proc_getcap}
+\end{figure}
+
+La sezione principale del programma è riportata in fig.~\ref{fig:proc_getcap},
+e si basa su una condizione sulla variabile \var{pid} che se si è usato
+l'opzione \texttt{-p} è impostata (nella sezione di gestione delle opzioni,
+che si è tralasciata) al valore del \textsl{pid} del processo di cui si vuole
+leggere le \textit{capabilities} e nulla altrimenti. Nel primo caso
+(\texttt{\small 1--6}) si utilizza direttamente (\texttt{\small 2})
+\func{cap\_get\_proc} per ottenere lo stato delle capacità del processo, nel
+secondo (\texttt{\small 7--14}) prima si inizializza (\texttt{\small 8}) uno
+stato vuoto e poi (\texttt{\small 9}) si legge il valore delle capacità del
+processo indicato.
+
+Il passo successivo è utilizzare (\texttt{\small 16}) \func{cap\_to\_text} per
+tradurre in una stringa lo stato, e poi (\texttt{\small 17}) stamparlo; infine
+(\texttt{\small 19--20}) si libera la memoria allocata dalle precedenti
+funzioni con \func{cap\_free} per poi ritornare dal ciclo principale della
+funzione.
\itindend{capabilities}
+% TODO vedi http://lwn.net/Articles/198557/ e
+% http://www.madore.org/~david/linux/newcaps/
+% TODO documentare prctl ...
+
\section{La gestione della priorità di esecuzione}
\label{sec:proc_priority}
In questa sezione tratteremo più approfonditamente i meccanismi con il quale
-lo \textit{scheduler}\itindex{scheduler} assegna la CPU ai vari processi
+lo \itindex{scheduler} \textit{scheduler} assegna la CPU ai vari processi
attivi. In particolare prenderemo in esame i vari meccanismi con cui viene
gestita l'assegnazione del tempo di CPU, ed illustreremo le varie funzioni di
gestione.
\label{sec:proc_sched}
\itindbeg{scheduler}
+
La scelta di un meccanismo che sia in grado di distribuire in maniera efficace
il tempo di CPU per l'esecuzione dei processi è sempre una questione delicata,
ed oggetto di numerose ricerche; in generale essa dipende in maniera
cui non esiste un meccanismo che sia valido per tutti gli usi.
La caratteristica specifica di un sistema multitasking come Linux è quella del
-cosiddetto \itindex{prehemptive~multitasking}\textit{prehemptive
+cosiddetto \itindex{prehemptive~multitasking} \textit{prehemptive
multitasking}: questo significa che al contrario di altri sistemi (che usano
-invece il cosiddetto \itindex{cooperative~multitasking}\textit{cooperative
+invece il cosiddetto \itindex{cooperative~multitasking} \textit{cooperative
multitasking}) non sono i singoli processi, ma il kernel stesso a decidere
quando la CPU deve essere passata ad un altro processo. Come accennato in
sez.~\ref{sec:proc_hierarchy} questa scelta viene eseguita da una sezione
Adeos gestiti dalle code del nano-kernel), in modo da poterli controllare
direttamente qualora ci sia la necessità di avere un processo con priorità
più elevata di un \textit{interrupt handler}.} mentre con l'incorrere in un
-\textit{page fault}\itindex{page~fault} si possono avere ritardi non previsti.
-Se l'ultimo problema può essere aggirato attraverso l'uso delle funzioni di
-controllo della memoria virtuale (vedi sez.~\ref{sec:proc_mem_lock}), il primo
-non è superabile e può comportare ritardi non prevedibili riguardo ai tempi di
-esecuzione di qualunque processo.
+\itindex{page~fault} \textit{page fault} si possono avere ritardi non
+previsti. Se l'ultimo problema può essere aggirato attraverso l'uso delle
+funzioni di controllo della memoria virtuale (vedi
+sez.~\ref{sec:proc_mem_lock}), il primo non è superabile e può comportare
+ritardi non prevedibili riguardo ai tempi di esecuzione di qualunque processo.
Occorre usare le priorità assolute con molta attenzione: se si dà ad un
processo una priorità assoluta e questo finisce in un loop infinito, nessun
funzioni che permettono di controllare in maniera più dettagliata la scelta di
quale processore utilizzare per eseguire un certo programma. Uno dei problemi
che si pongono nei sistemi multiprocessore è infatti quello
-dell'\textsl{effetto ping-pong}.\index{effetto~ping-pong} Può accadere cioè
+\index{effetto~ping-pong} dell'\textsl{effetto ping-pong}. Può accadere cioè
che lo scheduler, quando riavvia un processo precedentemente interrotto,
scegliendo il primo processore disponibile lo faccia eseguire da un processore
diverso rispetto a quello su cui era stato eseguito in precedenza. Se il
disponibile.
\itindbeg{CPU~affinity}
+
Per ovviare a questo tipo di problemi è nato il concetto di \textsl{affinità
di processore} (o \textit{CPU affinity}); la
possibilità cioè di far sì che un processo possa essere assegnato per
\texttt{len} è stato eliminato, successivamente si è introdotta la versione
riportata con però un secondo argomento di tipo \texttt{size\_t cpusetsize}
(anche questa citata nella pagina di manuale); la versione citata è quella
- riportata nel manuale delle \textsl{glibc} e corripondente alla definizione
+ riportata nel manuale delle \textsl{glibc} e corrispondente alla definizione
presente in \file{sched.h}.} è:
\begin{prototype}{sched.h}
{int sched\_setaffinity (pid\_t pid, const cpu\_set\_t *cpuset)}
Per facilitare l'uso dell'argomento \param{cpuset} le \acr{glibc} hanno
introdotto un apposito dato di tipo, \ctyp{cpu\_set\_t},\footnote{questa è una
estensione specifica delle \acr{glibc}, da attivare definendo la macro
- \macro{\_GNU\_SOURCE}, non esiste infatti una standardardizzazione per
+ \macro{\_GNU\_SOURCE}, non esiste infatti una standardizzazione per
questo tipo di interfaccia e POSIX al momento non prevede nulla al
riguardo.} che permette di identificare un insieme di processori. Il dato è
una maschera binaria: in generale è un intero a 32 bit in cui ogni bit
La funzione restituirà all'indirizzo specificato da \param{cpuset} il valore
della maschera di affinità del processo, così da poterla riutilizzare per una
successiva reimpostazione. In questo caso non sono necessari privilegi
-paricolari.
+particolari.
È chiaro che queste funzioni per la gestione dell'affinità hanno significato
soltanto su un sistema multiprocessore, esse possono comunque essere
utilizzate anche in un sistema con un processore singolo, nel qual caso però
non avranno alcun risultato effettivo.
+
\itindend{scheduler}
\itindend{CPU~affinity}
In un ambiente multitasking il concetto è essenziale, dato che un processo può
essere interrotto in qualunque momento dal kernel che mette in esecuzione un
altro processo o dalla ricezione di un segnale; occorre pertanto essere
-accorti nei confronti delle possibili \textit{race
- condition}\itindex{race~condition} (vedi sez.~\ref{sec:proc_race_cond})
-derivanti da operazioni interrotte in una fase in cui non erano ancora state
-completate.
+accorti nei confronti delle possibili \itindex{race~condition} \textit{race
+ condition} (vedi sez.~\ref{sec:proc_race_cond}) derivanti da operazioni
+interrotte in una fase in cui non erano ancora state completate.
Nel caso dell'interazione fra processi la situazione è molto più semplice, ed
occorre preoccuparsi della atomicità delle operazioni solo quando si ha a che
condivisa. In questi casi, se non si dispone della possibilità di eseguire
atomicamente le operazioni necessarie, occorre che quelle parti di codice in
cui si compiono le operazioni sulle risorse condivise (le cosiddette
-\textsl{sezioni critiche}\index{sezioni~critiche}) del programma, siano
+\index{sezione~critica} \textsl{sezioni critiche}) del programma, siano
opportunamente protette da meccanismi di sincronizzazione (torneremo su queste
problematiche di questo tipo in cap.~\ref{cha:IPC}).
delle funzioni all'interno dei gestori dei segnali.
Fintanto che una funzione opera soltanto con le variabili locali è rientrante;
-queste infatti vengono allocate nello \itindex{stack} stack, e un'altra
+queste infatti vengono allocate nello \itindex{stack} stack, ed un'altra
invocazione non fa altro che allocarne un'altra copia. Una funzione può non
essere rientrante quando opera su memoria che non è nello \itindex{stack}
stack. Ad esempio una funzione non è mai rientrante se usa una variabile
varie funzioni di libreria, che sono identificate aggiungendo il suffisso
\code{\_r} al nome della versione normale.
-
+% LocalWords: multitasking like VMS child process identifier pid sez shell fig
+% LocalWords: parent kernel init pstree keventd kswapd table struct linux call
+% LocalWords: nell'header scheduler system interrupt timer HZ asm Hertz clock
+% LocalWords: l'alpha tick fork wait waitpid exit exec image glibc int pgid ps
+% LocalWords: sid threads thread Ingo Molnar ppid getpid getppid sys unistd LD
+% LocalWords: void ForkTest tempnam pathname sibling cap errno EAGAIN ENOMEM
+% LocalWords: stack read only copy write tab client spawn forktest sleep PATH
+% LocalWords: source LIBRARY scheduling race condition printf descriptor dup
+% LocalWords: close group session tms lock vfork execve BSD stream main abort
+% LocalWords: SIGABRT SIGCHLD SIGHUP foreground SIGCONT termination signal ANY
+% LocalWords: handler kill EINTR POSIX options WNOHANG ECHILD option WUNTRACED
+% LocalWords: dump bits rusage getrusage heap const filename argv envp EACCES
+% LocalWords: filesystem noexec EPERM suid sgid root nosuid ENOEXEC ENOENT ELF
+% LocalWords: ETXTBSY EINVAL ELIBBAD BIG EFAULT EIO ENAMETOOLONG ELOOP ENOTDIR
+% LocalWords: ENFILE EMFILE argc execl path execv execle execlp execvp vector
+% LocalWords: list environ NULL umask pending utime cutime ustime fcntl linker
+% LocalWords: opendir libc interpreter FreeBSD capabilities Mandatory Access
+% LocalWords: Control MAC SELinux Security Modules LSM superuser uid gid saved
+% LocalWords: effective euid egid dell' fsuid fsgid getuid geteuid getgid SVr
+% LocalWords: getegid IDS NFS setuid setgid all' logout utmp screen xterm TODO
+% LocalWords: setreuid setregid FIXME ruid rgid seteuid setegid setresuid size
+% LocalWords: setresgid getresuid getresgid value result argument setfsuid DAC
+% LocalWords: setfsgid NGROUPS sysconf getgroups getgrouplist groups ngroups
+% LocalWords: setgroups initgroups patch LIDS CHOWN OVERRIDE Discrectionary PF
+% LocalWords: SEARCH chattr sticky NOATIME socket domain immutable append mmap
+% LocalWords: broadcast multicast multicasting memory locking mlock mlockall
+% LocalWords: shmctl ioperm iopl chroot ptrace accounting swap reboot hangup
+% LocalWords: vhangup mknod lease permitted inherited inheritable bounding AND
+% LocalWords: capability capget capset header ESRCH undef version obj clear PT
+% LocalWords: pag ssize length proc capgetp prehemptive cache runnable Stopped
+% LocalWords: Uninterrutible SIGSTOP soft slice nice niceness counter which SC
+% LocalWords: getpriority who setpriority RTLinux RTAI Adeos fault FIFO First
+% LocalWords: yield Robin setscheduler policy param OTHER priority setparam to
+% LocalWords: min getparam getscheduler interval robin ENOSYS fifo ping long
+% LocalWords: affinity setaffinity unsigned mask cpu NUMA CLR ISSET SETSIZE RR
+% LocalWords: getaffinity assembler deadlock REENTRANT SAFE tgz MYPGRP l'OR rr
+% LocalWords: WIFEXITED WEXITSTATUS WIFSIGNALED WTERMSIG WCOREDUMP WIFSTOPPED
+% LocalWords: WSTOPSIG opt char INTERP arg SIG IGN DFL mascheck grp FOWNER RAW
+% LocalWords: FSETID SETPCAP BIND SERVICE ADMIN PACKET IPC OWNER MODULE RAWIO
+% LocalWords: PACCT RESOURCE TTY CONFIG SETFCAP hdrp datap libcap lcap text tp
+% LocalWords: get ncap caps CapInh CapPrm fffffeff CapEff getcap STAT dall'I
+% LocalWords: inc PRIO SUSv PRGR prio SysV SunOS Ultrix sched timespec len sig
+% LocalWords: cpusetsize cpuset atomic
%%% Local Variables:
%%% mode: latex
projects / gapil.git / blobdiff