X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=prochand.tex;h=3ba60c60c22e22ec53dc4332903a165f0da4e22d;hp=3a142fc9daf884e4626ab2e79eb6608cafa45942;hb=dfc23dbc3caad01544e73d2488f8490d9260ebae;hpb=570997eb16e7228f83d94108b9cb095b7c7a0f2a diff --git a/prochand.tex b/prochand.tex index 3a142fc..3ba60c6 100644 --- a/prochand.tex +++ b/prochand.tex @@ -1,6 +1,6 @@ %% prochand.tex %% -%% Copyright (C) 2000-2012 Simone Piccardi. Permission is granted to +%% Copyright (C) 2000-2015 by 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", @@ -80,10 +80,8 @@ posto.\footnote{la cosa si fa passando la riga \cmd{init=/bin/sh} come \begin{figure}[!htb] \footnotesize -\begin{Command} -[piccardi@gont piccardi]$ pstree -n -\end{Command} -\begin{Terminal} +\begin{Console} +[piccardi@gont piccardi]$ \textbf{pstree -n} init-+-keventd |-kapm-idled |-kreiserfsd @@ -115,7 +113,7 @@ init-+-keventd |-5*[getty] |-snort `-wwwoffled -\end{Terminal} +\end{Console} %$ \caption{L'albero dei processi, così come riportato dal comando \cmd{pstree}.} @@ -155,17 +153,18 @@ in fig.~\ref{fig:proc_task_struct}. % http://www.ibm.com/developerworks/linux/library/l-linux-process-management/ % TODO completare la parte su quando viene chiamato lo scheduler. -Come accennato in sez.~\ref{sec:intro_unix_struct} è lo \itindex{scheduler} -\textit{scheduler} che decide quale processo mettere in esecuzione; esso viene -eseguito in occasione di dell'invocazione di ogni \textit{system call} ed per -ogni interrupt dall'hardware oltre che in una serie di altre occasioni, e può -essere anche attivato esplicitamente. Il timer di sistema provvede comunque a -che esso sia invocato periodicamente, generando un interrupt periodico secondo -una frequenza predeterminata, specificata dalla costante \const{HZ} del kernel -(torneremo su questo argomento in sez.~\ref{sec:sys_unix_time}), che assicura -che lo \textit{scheduler} scheduler venga comunque eseguito ad intervalli -regolari e possa prendere le sue decisioni. +\itindbeg{scheduler} +Come accennato in sez.~\ref{sec:intro_unix_struct} è lo \textit{scheduler} che +decide quale processo mettere in esecuzione; esso viene eseguito in occasione +di dell'invocazione di ogni \textit{system call} ed per ogni interrupt +dall'hardware oltre che in una serie di altre occasioni, e può essere anche +attivato esplicitamente. Il timer di sistema provvede comunque a che esso sia +invocato periodicamente, generando un interrupt periodico secondo una +frequenza predeterminata, specificata dalla costante \const{HZ} del kernel +(torneremo su questo argomento in sez.~\ref{sec:sys_unix_time}), che assicura +che lo \textit{scheduler} venga comunque eseguito ad intervalli regolari e +possa prendere le sue decisioni. A partire dal kernel 2.6.21 è stato introdotto anche un meccanismo completamente diverso, detto \textit{tickless}, in cui non c'è più una @@ -177,11 +176,12 @@ dell'energia da parte del processore che può essere messo in stato di sospensione anche per lunghi periodi di tempo. Indipendentemente dalle motivazioni per cui questo avviene, 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. +viene eseguito lo \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. +\itindend{scheduler} \subsection{Gli identificatori dei processi} \label{sec:proc_pid} @@ -385,26 +385,23 @@ distribuito insieme agli altri sorgenti degli esempi su \url{http://gapil.truelite.it/gapil_source.tgz}. Decifrato il numero di figli da creare, il ciclo principale del programma -(\texttt{\small 24--40}) esegue in successione la creazione dei processi figli +(\texttt{\small 24-40}) esegue in successione la creazione dei processi figli controllando il successo della chiamata a \func{fork} (\texttt{\small - 25--29}); ciascun figlio (\texttt{\small 31--34}) si limita a stampare il + 25-29}); ciascun figlio (\texttt{\small 31-34}) si limita a stampare il suo numero di successione, eventualmente attendere il numero di secondi specificato e scrivere un messaggio prima di uscire. Il processo padre invece -(\texttt{\small 36--38}) stampa un messaggio di creazione, eventualmente +(\texttt{\small 36-38}) stampa un messaggio di creazione, eventualmente attende il numero di secondi specificato, e procede nell'esecuzione del ciclo; alla conclusione del ciclo, prima di uscire, può essere specificato un altro periodo di attesa. Se eseguiamo il comando, che è preceduto dall'istruzione \code{export LD\_LIBRARY\_PATH=./} per permettere l'uso delle librerie dinamiche, senza -specificare attese (come si può notare in (\texttt{\small 17--19}) i valori +specificare attese (come si può notare in (\texttt{\small 17-19}) i valori predefiniti specificano di non attendere), otterremo come risultato sul terminale: -\begin{Command} -[piccardi@selidor sources]$ export LD_LIBRARY_PATH=./; ./forktest 3 -\end{Command} -%$ -\begin{Terminal} +\begin{Console} +[piccardi@selidor sources]$ \textbf{export LD_LIBRARY_PATH=./; ./forktest 3} Process 1963: forking 3 child Spawned 1 child, pid 1964 Child 1 successfully executing @@ -418,7 +415,8 @@ Child 3 successfully executing Child 3, parent 1963, exiting Spawned 3 child, pid 1966 Go to next child -\end{Terminal} +\end{Console} +%$ 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 @@ -431,12 +429,12 @@ mentre la terza volta è stato prima eseguito il figlio (fino alla conclusione) e poi il padre. In generale l'ordine di esecuzione dipenderà, oltre che dall'algoritmo di -\itindex{scheduler} \textit{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. +\textit{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 @@ -445,18 +443,18 @@ occorrerà provvedere ad espliciti meccanismi di sincronizzazione, pena il rischio di incorrere nelle cosiddette \itindex{race~condition} \textit{race condition} (vedi sez.~\ref{sec:proc_race_cond}). -In realtà con l'introduzione dei kernel della serie 2.6 lo \itindex{scheduler} -\textit{scheduler} è stato modificato per eseguire sempre per primo il -figlio.\footnote{i risultati precedenti infatti sono stati ottenuti usando un - kernel della serie 2.4.} Questa è una ottimizzazione adottata per evitare -che il padre, effettuando per primo una operazione di scrittura in memoria, -attivasse il meccanismo del \itindex{copy~on~write} \textit{copy on write}, -operazione inutile qualora il figlio venga creato solo per eseguire una -\func{exec} su altro programma che scarta completamente lo spazio degli -indirizzi e rende superflua la copia della memoria modificata dal -padre. Eseguendo sempre per primo il figlio la \func{exec} verrebbe effettuata -subito, con la certezza di utilizzare \itindex{copy~on~write} \textit{copy on - write} solo quando necessario. +In realtà con l'introduzione dei kernel della serie 2.6 lo \textit{scheduler} +è stato modificato per eseguire sempre per primo il figlio.\footnote{i + risultati precedenti infatti sono stati ottenuti usando un kernel della + serie 2.4.} Questa è una ottimizzazione adottata per evitare che il padre, +effettuando per primo una operazione di scrittura in memoria, attivasse il +meccanismo del \itindex{copy~on~write} \textit{copy on write}, operazione +inutile qualora il figlio venga creato solo per eseguire una \func{exec} su +altro programma che scarta completamente lo spazio degli indirizzi e rende +superflua la copia della memoria modificata dal padre. Eseguendo sempre per +primo il figlio la \func{exec} verrebbe effettuata subito, con la certezza di +utilizzare \itindex{copy~on~write} \textit{copy on write} solo quando +necessario. Con il kernel 2.6.32 però il comportamento è stato nuovamente cambiato, stavolta facendo eseguire per primo sempre il padre. Si è realizzato infatti @@ -488,11 +486,9 @@ se buona parte dei concetti relativi ai file verranno trattati più avanti (principalmente in sez.~\ref{sec:file_unix_interface}). Per illustrare meglio quello che avviene si può redirigere su un file l'output del programma di test, quello che otterremo è: -\begin{Command} -[piccardi@selidor sources]$ ./forktest 3 > output -[piccardi@selidor sources]$ cat output -\end{Command} -\begin{Terminal} +\begin{Console} +[piccardi@selidor sources]$ \textbf{./forktest 3 > output} +[piccardi@selidor sources]$ \textbf{cat output} Process 1967: forking 3 child Child 1 successfully executing Child 1, parent 1967, exiting @@ -515,31 +511,34 @@ Spawned 2 child, pid 1969 Go to next child Spawned 3 child, pid 1970 Go to next child -\end{Terminal} +\end{Console} che come si vede è completamente diverso da quanto ottenevamo sul terminale. Il comportamento delle varie funzioni di interfaccia con i file è analizzato in gran dettaglio in sez.~\ref{sec:file_unix_interface} per l'interfaccia nativa Unix ed in sez.~\ref{sec:files_std_interface} per la standardizzazione adottata nelle librerie del linguaggio C e valida per qualunque sistema -operativo. Qui basta accennare che si sono usate le funzioni standard della -libreria del C che prevedono l'output bufferizzato. Il punto è che questa -bufferizzazione (che tratteremo in dettaglio in sez.~\ref{sec:file_buffering}) -varia a seconda che si tratti di un file su disco, in cui il buffer viene -scaricato su disco solo quando necessario, o di un terminale, in cui il buffer -viene scaricato ad ogni carattere di a capo. +operativo. + +Qui basta accennare che si sono usate le funzioni standard della libreria del +C che prevedono l'output bufferizzato. Il punto è che questa bufferizzazione +(che tratteremo in dettaglio in sez.~\ref{sec:file_buffering}) varia a seconda +che si tratti di un file su disco, in cui il buffer viene scaricato su disco +solo quando necessario, o di un terminale, in cui il buffer viene scaricato ad +ogni carattere di a capo. Nel primo esempio allora avevamo che, essendovi un a capo nella stringa stampata, ad ogni chiamata a \func{printf} il buffer veniva scaricato, per cui le singole righe comparivano a video subito dopo l'esecuzione della \func{printf}. Ma con la redirezione su file la scrittura non avviene più alla -fine di ogni riga e l'output resta nel buffer. Dato che ogni figlio riceve una -copia della memoria del padre, esso riceverà anche quanto c'è nel buffer delle -funzioni di I/O, comprese le linee scritte dal padre fino allora. Così quando -il buffer viene scritto su disco all'uscita del figlio, troveremo nel file -anche tutto quello che il processo padre aveva scritto prima della sua -creazione. E alla fine del file (dato che in questo caso il padre esce per -ultimo) troveremo anche l'output completo del padre. +fine di ogni riga e l'output resta nel buffer. + +Dato che ogni figlio riceve una copia della memoria del padre, esso riceverà +anche quanto c'è nel buffer delle funzioni di I/O, comprese le linee scritte +dal padre fino allora. Così quando il buffer viene scritto su disco all'uscita +del figlio, troveremo nel file anche tutto quello che il processo padre aveva +scritto prima della sua creazione. E alla fine del file (dato che in questo +caso il padre esce per ultimo) troveremo anche l'output completo del padre. L'esempio ci mostra un altro aspetto fondamentale dell'interazione con i file, valido anche per l'esempio precedente, ma meno evidente: il fatto cioè che non @@ -550,17 +549,17 @@ avviene per le variabili in memoria, la posizione corrente sul file è condivisa fra il padre e tutti i processi figli. Quello che succede è che quando lo \textit{standard output}\footnote{si chiama - così il file su cui un programma scrive i suoi dati in uscita, tratteremo - l'argomento in dettaglio in sez.~\ref{sec:file_fd}.} del padre viene -rediretto come si è fatto nell'esempio, lo stesso avviene anche per tutti i -figli. La funzione \func{fork} infatti ha la caratteristica di duplicare nei -processi figli tutti i \textit{file descriptor} (vedi sez.~\ref{sec:file_fd}) -dei file aperti nel processo 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 \itindex{file~table} \textit{file - table} (tratteremo in dettaglio questi termini in -sez.~\ref{sec:file_shared_access}) fra cui c'è anche la posizione corrente nel -file. + così il file su cui di default un programma scrive i suoi dati in uscita, + tratteremo l'argomento in dettaglio in sez.~\ref{sec:file_fd}.} del padre +viene rediretto come si è fatto nell'esempio, lo stesso avviene anche per +tutti i figli. La funzione \func{fork} infatti ha la caratteristica di +duplicare nei processi figli tutti i \textit{file descriptor} (vedi +sez.~\ref{sec:file_fd}) dei file aperti nel processo 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 +\itindex{file~table} \textit{file table} (tratteremo in dettaglio questi +termini in sez.~\ref{sec:file_shared_access}) fra cui c'è anche la posizione +corrente nel file. In questo modo se un processo scrive su un file aggiornerà la posizione corrente sulla \itindex{file~table} \textit{file table}, e tutti gli altri @@ -600,12 +599,11 @@ Oltre ai file aperti i processi figli ereditano dal padre una serie di altre 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 \itindex{close-on-exec} - \textit{close-on-exec} impostati (vedi sez.~\ref{sec:proc_exec} e - sez.~\ref{sec:file_fcntl_ioctl}); +\item i file aperti e gli eventuali flag di \textit{close-on-exec} impostati + (vedi sez.~\ref{sec:proc_exec} e sez.~\ref{sec:file_fcntl_ioctl}); \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 + \textsl{group-ID effettivo} ed i \textsl{group-ID supplementari} (vedi sez.~\ref{sec:proc_access_id}); \item gli identificatori per il controllo di sessione: il \itindex{process~group} \textit{process group-ID} e il \textit{session id} @@ -614,7 +612,7 @@ comune dopo l'esecuzione di una \func{fork} è la seguente: (vedi sez.~\ref{sec:file_work_dir} e sez.~\ref{sec:file_chroot}); \item la maschera dei permessi di creazione dei file (vedi sez.~\ref{sec:file_perm_management}); -\item la \index{maschera~dei~segnali} maschera dei segnali bloccati (vedi +\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 @@ -782,10 +780,8 @@ stato di terminazione. Come verifica di questo comportamento possiamo eseguire il nostro programma \cmd{forktest} imponendo a ciascun processo figlio due secondi di attesa prima di uscire, il risultato è: -\begin{Command} -[piccardi@selidor sources]$ ./forktest -c2 3 -\end{Command} -\begin{Terminal}[commandchars=\\\{\}] +\begin{Console} +[piccardi@selidor sources]$ \textbf{./forktest -c2 3} Process 1972: forking 3 child Spawned 1 child, pid 1973 Child 1 successfully executing @@ -797,10 +793,10 @@ Child 3 successfully executing Spawned 3 child, pid 1975 Go to next child -\textbf{[piccardi@selidor sources]$} Child 3, parent 1, exiting +[piccardi@selidor sources]$ Child 3, parent 1, exiting Child 2, parent 1, exiting Child 1, parent 1, exiting -\end{Terminal} +\end{Console} come si può notare in questo caso il processo padre si conclude prima dei figli, tornando alla shell, che stampa il prompt sul terminale: circa due secondi dopo viene stampato a video anche l'output dei tre figli che @@ -831,11 +827,8 @@ condizione: lanciamo il comando \cmd{forktest} in \textit{background} (vedi sez.~\ref{sec:sess_job_control}), indicando al processo padre di aspettare 10 secondi prima di uscire. In questo caso, usando \cmd{ps} sullo stesso terminale (prima dello scadere dei 10 secondi) otterremo: -\begin{Command} -[piccardi@selidor sources]$ ps T -\end{Command} -%$ -\begin{Terminal} +\begin{Console} +[piccardi@selidor sources]$ \textbf{ps T} PID TTY STAT TIME COMMAND 419 pts/0 S 0:00 bash 568 pts/0 S 0:00 ./forktest -e10 3 @@ -843,7 +836,8 @@ terminale (prima dello scadere dei 10 secondi) otterremo: 570 pts/0 Z 0:00 [forktest ] 571 pts/0 Z 0:00 [forktest ] 572 pts/0 R 0:00 ps T -\end{Terminal} +\end{Console} +%$ 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 \itindex{zombie} \textit{zombie} e l'indicazione che @@ -851,18 +845,18 @@ sono terminati (la scritta \texttt{defunct}). La possibilità di avere degli \itindex{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}) di cui vedremo un esempio in -fig.~\ref{fig:sig_sigchld_handl}. - -Questa operazione è necessaria perché anche se gli \itindex{zombie} -\textit{zombie} non consumano risorse di memoria o processore, occupano -comunque una voce nella tabella dei processi e se li si lascia accumulare a -lungo quest'ultima potrebbe riempirsi, con l'impossibilità di lanciare nuovi -processi. +in esecuzione a lungo e creare molti processi figli. In questo caso si deve +sempre avere cura di far leggere al programma l'eventuale stato di uscita di +tutti i figli. Una modalità comune di farlo è attraverso l'utilizzo di un +apposito \textit{signal handler} che chiami la funzione \func{wait}, (vedi +sez.~\ref{sec:proc_wait}), ne esamineremo in dettaglio un esempio +(fig.~\ref{fig:sig_sigchld_handl}) in sez.~\ref{sec:sig_sigchld}. + +La lettura degli stati di uscita è necessaria perché anche se gli +\itindex{zombie} \textit{zombie} non consumano risorse di memoria o +processore, occupano comunque una voce nella tabella dei processi e se li si +lasciano accumulare a lungo quest'ultima potrebbe esaurirsi, con la +conseguente impossibilità di lanciare nuovi processi. Si noti tuttavia che quando un processo adottato da \cmd{init} termina, non diviene mai uno \itindex{zombie} \textit{zombie}. Questo perché una delle @@ -878,9 +872,16 @@ provvede a completarne la terminazione. Si tenga presente infine che siccome gli \itindex{zombie} \textit{zombie} sono processi già terminati, non c'è modo di eliminarli con il comando \cmd{kill} o inviandogli un qualunque segnale di terminazione (l'argomento è trattato in -sez.~\ref{sec:sig_termination}). 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 concluderne la terminazione. +sez.~\ref{sec:sig_termination}). Qualora ci si trovi in questa situazione +l'unica possibilità di cancellarli dalla tabella dei processi è quella di +terminare il processo che li ha generati e che non sta facendo il suo lavoro, +in modo che \cmd{init} possa adottarli e concluderne correttamente la +terminazione. + +Si tenga anche presente che la presenza di \textit{zombie} nella tabella dei +processi non è sempre indice di un qualche malfunzionamento, in una macchina +con molto carico infatti può esservi una presenza temporanea dovuta al fatto +che il processo padre ancora non ha avuto il tempo di gestirli. \subsection{Le funzioni di attesa e ricezione degli stati di uscita} \label{sec:proc_wait} @@ -1376,7 +1377,7 @@ Ci sono sei diverse versioni di \func{exec} (per questo la si è chiamata famiglia di funzioni) che possono essere usate per questo compito, in realtà (come mostrato in fig.~\ref{fig:proc_exec_relat}), tutte queste funzioni sono tutte varianti che consentono di invocare in modi diversi, semplificando il -passaggio degli argomenti, la \textit{system call} \funcd{execve}, il cui +passaggio degli argomenti, la funzione di sistema \funcd{execve}, il cui prototipo è: \begin{funcproto}{ @@ -1501,7 +1502,7 @@ convenzione che il primo argomento (\var{arg0} o \var{argv[0]}) viene usato per indicare il nome del file che contiene il programma che verrà eseguito. \begin{figure}[!htb] - \centering \includegraphics[width=10cm]{img/exec_rel} + \centering \includegraphics[width=9cm]{img/exec_rel} \caption{La interrelazione fra le sei funzioni della famiglia \func{exec}.} \label{fig:proc_exec_relat} \end{figure} @@ -1537,7 +1538,7 @@ seguente: \begin{itemize*} \item il \textit{process id} (\ids{PID}) ed il \textit{parent process id} (\ids{PPID}); -\item l'\textsl{user-ID reale}, il \textit{group-ID reale} ed i +\item l'\textsl{user-ID reale}, il \textsl{group-ID reale} ed i \textsl{group-ID supplementari} (vedi sez.~\ref{sec:proc_access_id}); \item la directory radice e la \index{directory~di~lavoro} directory di lavoro corrente (vedi sez.~\ref{sec:file_work_dir}); @@ -1557,8 +1558,7 @@ seguente: % TODO ===========Importante============= % TODO questo sotto è incerto, verificare % TODO ===========Importante============= -\item la \index{maschera~dei~segnali} maschera dei segnali (si veda - sez.~\ref{sec:sig_sigmask}). +\item la maschera dei segnali (si veda sez.~\ref{sec:sig_sigmask}). \end{itemize*} Una serie di proprietà del processo originale, che non avrebbe senso mantenere @@ -1601,9 +1601,9 @@ nell'esecuzione della funzione \func{exec}, queste sono: \begin{itemize*} \item le operazioni di I/O asincrono (vedi sez.~\ref{sec:file_asyncronous_io}) pendenti vengono cancellate; -\item le \itindex{capabilities} \textit{capabilities} vengono modificate come +\item le \textit{capabilities} vengono modificate come illustrato in sez.~\ref{sec:proc_capabilities}; -\item tutti i \itindex{thread} \textit{thread} tranne il chiamante (vedi +\item tutti i \textit{thread} tranne il chiamante (vedi sez.~\ref{sec:thread_xxx}) sono cancellati e tutti gli oggetti ad essi relativi (vedi sez.~\ref{sec:thread_xxx}) rimossi; \item viene impostato il flag \const{PR\_SET\_DUMPABLE} di \func{prctl} (vedi @@ -1619,18 +1619,23 @@ nell'esecuzione della funzione \func{exec}, queste sono: localizzazione al valore di default POSIX. \end{itemize*} +\itindbeg{close-on-exec} + La gestione dei file aperti nel passaggio al nuovo programma lanciato con -\func{exec} dipende dal valore che ha il flag di \itindex{close-on-exec} -\textit{close-on-exec} (vedi sez.~\ref{sec:file_fcntl_ioctl}) per ciascun -\textit{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 attraverso una \func{exec}, a meno di una chiamata -esplicita a \func{fcntl} che imposti il suddetto flag. 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 +\func{exec} dipende dal valore che ha il flag di \textit{close-on-exec} (vedi +sez.~\ref{sec:file_fcntl_ioctl}) per ciascun \textit{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 attraverso una \func{exec}, a meno di una chiamata esplicita a +\func{fcntl} che imposti il suddetto flag. 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 -\itindex{close-on-exec} \textit{close-on-exec} sulle directory che apre, in -maniera trasparente all'utente. +\textit{close-on-exec} sulle directory che apre, in maniera trasparente +all'utente. + +\itindend{close-on-exec} + Il comportamento della funzione in relazione agli identificatori relativi al controllo di accesso verrà trattato in dettaglio in sez.~\ref{sec:proc_perms}, @@ -1649,13 +1654,13 @@ file appartiene. Se il file da eseguire è in formato \emph{a.out} e necessita di librerie condivise, viene lanciato il \textit{linker} dinamico \cmd{/lib/ld.so} prima del programma per caricare le librerie necessarie ed effettuare il link -dell'eseguibile.\footnote{il formato è ormai in completo disuso, per cui è - molto probabile che non il relativo supporto non sia disponibile.} Se il -programma è in formato ELF per caricare le librerie dinamiche viene usato -l'interprete indicato nel segmento \const{PT\_INTERP} previsto dal formato -stesso, in genere questo è \sysfile{/lib/ld-linux.so.1} per programmi -collegati con la \acr{libc5}, e \sysfile{/lib/ld-linux.so.2} per programmi -collegati con la \acr{glibc}. +dell'eseguibile; il formato è ormai in completo disuso, per cui è molto +probabile che non il relativo supporto non sia disponibile. Se il programma è +in formato ELF per caricare le librerie dinamiche viene usato l'interprete +indicato nel segmento \const{PT\_INTERP} previsto dal formato stesso, in +genere questo è \sysfile{/lib/ld-linux.so.1} per programmi collegati con la +\acr{libc5}, e \sysfile{/lib/ld-linux.so.2} per programmi collegati con la +\acr{glibc}. Infine nel caso il programma che si vuole eseguire sia uno script e non un binario, questo deve essere un file di testo che deve iniziare con una linea @@ -1665,15 +1670,17 @@ nella forma: \end{Example} dove l'interprete indicato deve essere un eseguibile binario e 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'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 restituisce un errore di - \const{ENAMETOOLONG}, una comparazione dei vari comportamenti si trova su - \url{http://www.in-ulm.de/~mascheck/various/shebang/}.} +\cmd{interpreter [argomenti] filename}. + +Si tenga presente che con Linux quanto viene scritto 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 restituisce un errore di +\const{ENAMETOOLONG}; una comparazione dei vari comportamenti sui diversi +sistemi unix-like si trova su +\url{http://www.in-ulm.de/~mascheck/various/shebang/}. Con la famiglia delle \func{exec} si chiude il novero delle funzioni su cui è basata la gestione tradizionale dei processi in Unix: con \func{fork} si crea @@ -1699,21 +1706,20 @@ problematiche connesse ad una gestione accorta dei privilegi. Come accennato in sez.~\ref{sec:intro_multiuser} il modello base\footnote{in 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 (vedi sez.~\ref{sec:file_ACL}) o il - \itindex{Mandatory~Access~Control~(MAC)} \textit{Mandatory Access Control} - di \index{SELinux} SELinux; inoltre basandosi sul lavoro effettuato con - SELinux, a partire dal kernel 2.5.x, è iniziato lo sviluppo di una - infrastruttura di sicurezza, i \itindex{Linux~Security~Modules} - \textit{Linux Security Modules}, o LSM, in grado di fornire diversi agganci - a livello del kernel per modularizzare tutti i possibili controlli di - accesso, cosa che ha permesso di realizzare diverse alternative a - \index{SELinux} SELinux.} 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. + flessibile e controllabile, come le \textit{capabilities} illustrate in + sez.~\ref{sec:proc_capabilities}, le ACL per i file (vedi + sez.~\ref{sec:file_ACL}) o il \textit{Mandatory Access Control} di + \textit{SELinux}; inoltre basandosi sul lavoro effettuato con + \textit{SELinux}, a partire dal kernel 2.5.x, è iniziato lo sviluppo di una + infrastruttura di sicurezza, i \textit{Linux Security Modules}, o LSM, in + grado di fornire diversi agganci a livello del kernel per modularizzare + tutti i possibili controlli di accesso, cosa che ha permesso di realizzare + diverse alternative a \textit{SELinux}.} +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 \itindex{User~ID~(PID)} \textsl{User-ID} @@ -2211,10 +2217,10 @@ chiamata con un vettore di dimensioni adeguate. Infine per impostare i gruppi supplementari di un processo ci sono due funzioni, che possono essere usate solo se si hanno i privilegi di -amministratore.\footnote{e più precisamente se si ha la \itindex{capabilities} - \textit{capability} \macro{CAP\_SETGID}.} La prima delle due è la funzione -di sistema \funcd{setgroups},\footnote{la funzione è definita in BSD e SRv4, - ma a differenza di \func{getgroups} non è stata inclusa in POSIX.1-2001, per +amministratore.\footnote{e più precisamente se si ha la \textit{capability} + \macro{CAP\_SETGID}.} La prima delle due è la funzione di sistema +\funcd{setgroups},\footnote{la funzione è definita in BSD e SRv4, ma a + differenza di \func{getgroups} non è stata inclusa in POSIX.1-2001, per poterla utilizzare deve essere definita la macro \macro{\_BSD\_SOURCE}.} ed il suo prototipo è: @@ -2274,11 +2280,11 @@ scrivere codice portabile. \label{sec:proc_priority} In questa sezione tratteremo più approfonditamente i meccanismi con il quale -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. Tratteremo infine anche le altre priorità dei processi (come quelle -per l'accesso a disco) divenute disponibili con i kernel più recenti. +lo \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. Tratteremo infine +anche le altre priorità dei processi (come quelle per l'accesso a disco) +divenute disponibili con i kernel più recenti. \subsection{I meccanismi di \textit{scheduling}} @@ -2428,32 +2434,33 @@ varia nel corso dell'esecuzione di un processo. Il meccanismo usato da Linux è in realtà piuttosto complesso,\footnote{e dipende strettamente dalla versione di kernel; in particolare a partire - dalla serie 2.6.x lo scheduler è stato riscritto completamente, con molte - modifiche susseguitesi per migliorarne le prestazioni, per un certo periodo - ed è stata anche introdotta la possibilità di usare diversi algoritmi, - selezionabili sia in fase di compilazione, che, nelle versioni più recenti, - all'avvio (addirittura è stato ideato un sistema modulare che permette di - cambiare lo scheduler a sistema attivo).} ma a grandi linee si può dire che -ad ogni processo è assegnata una \textit{time-slice}, cioè un intervallo di -tempo (letteralmente una fetta) per il quale, a meno di eventi esterni, esso -viene eseguito senza essere interrotto. Inoltre la priorità dinamica viene -calcolata dallo scheduler a partire da un valore iniziale che viene -\textsl{diminuito} tutte le volte che un processo è in stato \textit{runnable} -ma non viene posto in esecuzione.\footnote{in realtà il calcolo della priorità - dinamica e la conseguente scelta di quale processo mettere in esecuzione - avviene con un algoritmo molto più complicato, che tiene conto anche della - \textsl{interattività} del processo, utilizzando diversi fattori, questa è - una brutale semplificazione per rendere l'idea del funzionamento, per una - trattazione più dettagliata, anche se non aggiornatissima, dei meccanismi di - funzionamento dello scheduler si legga il quarto capitolo di - \cite{LinKernDev}.} Lo scheduler infatti mette sempre in esecuzione, fra -tutti i processi in stato \textit{runnable}, quello che ha il valore di -priorità dinamica più basso.\footnote{con le priorità dinamiche il significato - del valore numerico ad esse associato è infatti invertito, un valore più - basso significa una priorità maggiore.} Il fatto che questo valore venga -diminuito quando un processo non viene posto in esecuzione pur essendo pronto, -significa che la priorità dei processi che non ottengono l'uso del processore -viene progressivamente incrementata, così che anche questi alla fine hanno la + dalla serie 2.6.x lo \textit{scheduler} è stato riscritto completamente, con + molte modifiche susseguitesi per migliorarne le prestazioni, per un certo + periodo ed è stata anche introdotta la possibilità di usare diversi + algoritmi, selezionabili sia in fase di compilazione, che, nelle versioni + più recenti, all'avvio (addirittura è stato ideato un sistema modulare che + permette di cambiare lo \textit{scheduler} a sistema attivo).} ma a grandi +linee si può dire che ad ogni processo è assegnata una \textit{time-slice}, +cioè un intervallo di tempo (letteralmente una fetta) per il quale, a meno di +eventi esterni, esso viene eseguito senza essere interrotto. Inoltre la +priorità dinamica viene calcolata dallo \textit{scheduler} a partire da un +valore iniziale che viene \textsl{diminuito} tutte le volte che un processo è +in stato \textit{runnable} ma non viene posto in esecuzione.\footnote{in + realtà il calcolo della priorità dinamica e la conseguente scelta di quale + processo mettere in esecuzione avviene con un algoritmo molto più + complicato, che tiene conto anche della \textsl{interattività} del processo, + utilizzando diversi fattori, questa è una brutale semplificazione per + rendere l'idea del funzionamento, per una trattazione più dettagliata, anche + se non aggiornatissima, dei meccanismi di funzionamento dello + \textit{scheduler} si legga il quarto capitolo di \cite{LinKernDev}.} Lo +\textit{scheduler} infatti mette sempre in esecuzione, fra tutti i processi in +stato \textit{runnable}, quello che ha il valore di priorità dinamica più +basso.\footnote{con le priorità dinamiche il significato del valore numerico + ad esse associato è infatti invertito, un valore più basso significa una + priorità maggiore.} Il fatto che questo valore venga diminuito quando un +processo non viene posto in esecuzione pur essendo pronto, significa che la +priorità dei processi che non ottengono l'uso del processore viene +progressivamente incrementata, così che anche questi alla fine hanno la possibilità di essere eseguiti. Sia la dimensione della \textit{time-slice} che il valore di partenza della @@ -2462,9 +2469,9 @@ priorità dinamica sono determinate dalla cosiddetta \textit{nice} (o che ciascun processo si porta dietro, essa viene ereditata dai processi figli e mantenuta attraverso una \func{exec}; fino alla serie 2.4 essa era mantenuta nell'omonimo campo \texttt{nice} della \texttt{task\_struct}, con - la riscrittura dello scheduler eseguita nel 2.6 viene mantenuta nel campo - \texttt{static\_prio} come per le priorità statiche.} L'origine del nome di -questo parametro sta nel fatto che generalmente questo viene usato per + la riscrittura dello \textit{scheduler} eseguita nel 2.6 viene mantenuta nel + campo \texttt{static\_prio} come per le priorità statiche.} L'origine del +nome di questo parametro sta nel fatto che generalmente questo viene usato per \textsl{diminuire} la priorità di un processo, come misura di cortesia nei confronti degli altri. I processi infatti vengono creati dal sistema con un valore nullo e nessuno è privilegiato rispetto agli altri. Specificando un @@ -2500,13 +2507,12 @@ un valore qualunque, positivo o negativo, ed il sistema provvederà a troncare il risultato nell'intervallo consentito. Valori positivi comportano maggiore \textit{cortesia} e cioè una diminuzione della priorità, valori negativi comportano invece un aumento della priorità. Con i kernel precedenti il 2.6.12 -solo l'amministratore\footnote{o un processo con la \itindex{capabilities} - \textit{capability} \const{CAP\_SYS\_NICE}, vedi - sez.~\ref{sec:proc_capabilities}.} può specificare valori negativi -di \param{inc} che permettono di aumentare la priorità di un processo, a -partire da questa versione è consentito anche agli utenti normali alzare -(entro certi limiti, che vedremo in sez.~\ref{sec:sys_resource_limit}) la -priorità dei propri processi. +solo l'amministratore\footnote{o un processo con la \textit{capability} + \const{CAP\_SYS\_NICE}, vedi sez.~\ref{sec:proc_capabilities}.} può +specificare valori negativi di \param{inc} che permettono di aumentare la +priorità di un processo, a partire da questa versione è consentito anche agli +utenti normali alzare (entro certi limiti, che vedremo in +sez.~\ref{sec:sys_resource_limit}) la priorità dei propri processi. Gli standard SUSv2 e POSIX.1 prevedono che la funzione ritorni il nuovo valore di \textit{nice} del processo; tuttavia la \textit{system call} di Linux non @@ -2629,18 +2635,18 @@ anche in questo caso per rilevare un errore occorre sempre porre a zero \textit{nice} valido. Si tenga presente che solo l'amministratore\footnote{o più precisamente un - processo con la \itindex{capabilities} \textit{capability} - \const{CAP\_SYS\_NICE}, vedi sez.~\ref{sec:proc_capabilities}.} ha la -possibilità di modificare arbitrariamente le priorità di qualunque -processo. Un utente normale infatti può modificare solo la priorità dei suoi -processi ed in genere soltanto diminuirla. Fino alla versione di kernel -2.6.12 Linux ha seguito le specifiche dello standard SUSv3, e come per tutti i -sistemi derivati da SysV veniva richiesto che l'\ids{UID} reale o quello -effettivo del processo chiamante corrispondessero all'\ids{UID} reale (e solo -a quello) del processo di cui si intendeva cambiare la priorità. A partire -dalla versione 2.6.12 è stata adottata la semantica in uso presso i sistemi -derivati da BSD (SunOS, Ultrix, *BSD), in cui la corrispondenza può essere -anche con l'\ids{UID} effettivo. + processo con la \textit{capability} \const{CAP\_SYS\_NICE}, vedi + sez.~\ref{sec:proc_capabilities}.} ha la possibilità di modificare +arbitrariamente le priorità di qualunque processo. Un utente normale infatti +può modificare solo la priorità dei suoi processi ed in genere soltanto +diminuirla. Fino alla versione di kernel 2.6.12 Linux ha seguito le +specifiche dello standard SUSv3, e come per tutti i sistemi derivati da SysV +veniva richiesto che l'\ids{UID} reale o quello effettivo del processo +chiamante corrispondessero all'\ids{UID} reale (e solo a quello) del processo +di cui si intendeva cambiare la priorità. A partire dalla versione 2.6.12 è +stata adottata la semantica in uso presso i sistemi derivati da BSD (SunOS, +Ultrix, *BSD), in cui la corrispondenza può essere anche con l'\ids{UID} +effettivo. Sempre a partire dal kernel 2.6.12 è divenuto possibile anche per gli utenti ordinari poter aumentare la priorità dei propri processi specificando un @@ -2786,6 +2792,10 @@ corrente. \label{tab:proc_sched_policy} \end{table} +% TODO Aggiungere SCHED_DEADLINE, sulla nuova politica di scheduling aggiunta +% con il kernel 3.14, vedi anche Documentation/scheduler/sched-deadline.txt e +% http://lwn.net/Articles/575497/ + Con le versioni più recenti del kernel sono state introdotte anche delle varianti sulla politica di \textit{scheduling} tradizionale per alcuni carichi di lavoro specifici, queste due nuove politiche sono specifiche di Linux e non @@ -2793,15 +2803,15 @@ devono essere usate se si vogliono scrivere programmi portabili. La politica \const{SCHED\_BATCH} è una variante della politica ordinaria con la sola differenza che i processi ad essa soggetti non ottengono, nel calcolo -delle priorità dinamiche fatto dallo scheduler, il cosiddetto bonus di -interattività che mira a favorire i processi che si svegliano dallo stato di -\textit{sleep}.\footnote{cosa che accade con grande frequenza per i processi - interattivi, dato che essi sono per la maggior parte del tempo in attesa di - dati in ingresso da parte dell'utente.} La si usa pertanto, come indica il -nome, per processi che usano molta CPU (come programmi di calcolo) che in -questo modo sono leggermente sfavoriti rispetto ai processi interattivi che -devono rispondere a dei dati in ingresso, pur non perdendo il loro valore di -\textit{nice}. +delle priorità dinamiche fatto dallo \textit{scheduler}, il cosiddetto bonus +di interattività che mira a favorire i processi che si svegliano dallo stato +di \textit{sleep}.\footnote{cosa che accade con grande frequenza per i + processi interattivi, dato che essi sono per la maggior parte del tempo in + attesa di dati in ingresso da parte dell'utente.} La si usa pertanto, come +indica il nome, per processi che usano molta CPU (come programmi di calcolo) +che in questo modo sono leggermente sfavoriti rispetto ai processi interattivi +che devono rispondere a dei dati in ingresso, pur non perdendo il loro valore +di \textit{nice}. La politica \const{SCHED\_IDLE} invece è una politica dedicata ai processi che si desidera siano eseguiti con la più bassa priorità possibile, ancora più @@ -2876,7 +2886,7 @@ sarà reinserito in coda alla lista); l'esecuzione viene ripresa subito solo nel caso che esso sia stato interrotto da un processo a priorità più alta. Solo un processo con i privilegi di amministratore\footnote{più precisamente - con la \itindex{capabilities} capacità \const{CAP\_SYS\_NICE}, vedi + con la capacità \const{CAP\_SYS\_NICE}, vedi sez.~\ref{sec:proc_capabilities}.} può impostare senza restrizioni priorità assolute diverse da zero o politiche \const{SCHED\_FIFO} e \const{SCHED\_RR}. Un utente normale può modificare solo le priorità di @@ -3146,10 +3156,10 @@ possibile legare automaticamente un gruppo di processi ad un singolo processore. Nell'uso comune, almeno con i kernel successivi alla serie 2.6.x, l'uso di -questa funzione non è necessario, in quanto è lo scheduler stesso che provvede -a mantenere al meglio l'affinità di processore. Esistono però esigenze -particolari, ad esempio quando un processo (o un gruppo di processi) è -utilizzato per un compito importante (ad esempio per applicazioni +questa funzione non è necessario, in quanto è lo \textit{scheduler} stesso che +provvede a mantenere al meglio l'affinità di processore. Esistono però +esigenze particolari, ad esempio quando un processo (o un gruppo di processi) +è utilizzato per un compito importante (ad esempio per applicazioni \textit{real-time} o la cui risposta è critica) e si vuole la massima velocità, e con questa interfaccia diventa possibile selezionare gruppi di processori utilizzabili in maniera esclusiva. Lo stesso dicasi quando @@ -3348,7 +3358,6 @@ 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} @@ -3565,6 +3574,7 @@ questo caso non ci sono effetti sugli altri processi questo limite è stato rimosso a partire dal kernel 2.6.25. %TODO verificare http://lwn.net/Articles/355987/ + \section{Funzioni di gestione avanzata} \label{sec:proc_advanced_control} @@ -3614,26 +3624,24 @@ momento:\footnote{alla stesura di questa sezione, cioè con il kernel 3.2.} \begin{basedescript}{\desclabelwidth{2.cm}\desclabelstyle{\nextlinelabel}} \item[\const{PR\_CAPBSET\_READ}] Controlla la disponibilità di una delle - \itindex{capabilities} \textit{capabilities} (vedi - sez.~\ref{sec:proc_capabilities}). La funzione ritorna 1 se la capacità - specificata nell'argomento \param{arg2} (con una delle costanti di - tab.~\ref{tab:proc_capabilities}) è presente nel \textit{capabilities - bounding set} del processo e zero altrimenti, se \param{arg2} non è un - valore valido si avrà un errore di \errval{EINVAL}. Introdotta a partire - dal kernel 2.6.25. + \textit{capability} (vedi sez.~\ref{sec:proc_capabilities}). La funzione + ritorna 1 se la capacità specificata nell'argomento \param{arg2} (con una + delle costanti di tab.~\ref{tab:proc_capabilities}) è presente nel + \textit{capabilities bounding set} del processo e zero altrimenti, + se \param{arg2} non è un valore valido si avrà un errore di \errval{EINVAL}. + Introdotta a partire dal kernel 2.6.25. \item[\const{PR\_CAPBSET\_DROP}] Rimuove permanentemente una delle - \itindex{capabilities} \textit{capabilities} (vedi - sez.~\ref{sec:proc_capabilities}) dal processo e da tutti i suoi - discendenti. La funzione cancella la capacità specificata + \textit{capabilities} (vedi sez.~\ref{sec:proc_capabilities}) dal processo e + da tutti i suoi discendenti. La funzione cancella la capacità specificata nell'argomento \param{arg2} con una delle costanti di - tab.~\ref{tab:proc_capabilities} dal \textit{capabilities bounding set} - \itindex{capabilities~bounding~set} del processo. L'operazione richiede i - privilegi di amministratore (la capacità \const{CAP\_SETPCAP}), altrimenti - la chiamata fallirà con un errore di \errcode{EPERM}; se il valore - di \param{arg2} non è valido o se il supporto per le \textit{file - capabilities} non è stato compilato nel kernel la chiamata fallirà con un - errore di \errval{EINVAL}. Introdotta a partire dal kernel 2.6.25. + tab.~\ref{tab:proc_capabilities} dal \textit{capabilities bounding set} del + processo. L'operazione richiede i privilegi di amministratore (la capacità + \const{CAP\_SETPCAP}), altrimenti la chiamata fallirà con un errore di + \errcode{EPERM}; se il valore di \param{arg2} non è valido o se il supporto + per le \textit{file capabilities} non è stato compilato nel kernel la + chiamata fallirà con un errore di \errval{EINVAL}. Introdotta a partire dal + kernel 2.6.25. \item[\const{PR\_SET\_DUMPABLE}] Imposta il flag che determina se la terminazione di un processo a causa di un segnale per il quale è prevista la @@ -3715,8 +3723,8 @@ Introdotta a partire dal kernel 2.4.21, solo su PowerPC. a partire dal kernel 2.4.21, solo su PowerPC. \item[\const{PR\_SET\_KEEPCAPS}] Consente di controllare quali - \itindex{capabilities} \textit{capabilities} vengono cancellate quando si - esegue un cambiamento di \ids{UID} del processo (per i dettagli si veda + \textit{capabilities} vengono cancellate quando si esegue un cambiamento di + \ids{UID} del processo (per i dettagli si veda sez.~\ref{sec:proc_capabilities}, in particolare quanto illustrato a pag.~\pageref{sec:capability-uid-transition}). Un valore nullo (il default) per \param{arg2} comporta che vengano cancellate, il valore 1 che vengano @@ -3727,9 +3735,8 @@ Introdotta a partire dal kernel 2.4.21, solo su PowerPC. dal kernel 2.2.18. \item[\const{PR\_GET\_KEEPCAPS}] Ottiene come valore di ritorno della funzione - il valore del flag di controllo delle \itindex{capabilities} - \textit{capabilities} impostato con \const{PR\_SET\_KEEPCAPS}. Introdotta a - partire dal kernel 2.2.18. + il valore del flag di controllo delle \textit{capabilities} impostato con + \const{PR\_SET\_KEEPCAPS}. Introdotta a partire dal kernel 2.2.18. \item[\const{PR\_SET\_NAME}] Imposta il nome del processo chiamante alla stringa puntata da \param{arg2}, che deve essere di tipo ``\ctyp{char *}''. Il @@ -3773,6 +3780,14 @@ Introdotta a partire dal kernel 2.4.21, solo su PowerPC. Introdotta a partire dal kernel 2.6.23, disponibile solo se si è abilitato il supporto nel kernel con \texttt{CONFIG\_SECCOMP}. +% TODO a partire dal kernel 3.5 è stato introdotto la possibilità di usare un +% terzo argomento se il secondo è SECCOMP_MODE_FILTER, vedi +% Documentation/prctl/seccomp_filter.txt +% vedi anche http://lwn.net/Articles/600250/ + +% TODO a partire dal kernel 3.17 è stata introdotta la nuova syscall seccomp, +% vedi http://lwn.net/Articles/600250/ e http://lwn.net/Articles/603321/ + \item[\const{PR\_GET\_SECCOMP}] Ottiene come valore di ritorno della funzione lo stato corrente del \textit{secure computing mode}, al momento attuale la funzione è totalmente inutile in quanto l'unico valore ottenibile è 0, dato @@ -3786,9 +3801,9 @@ Introdotta a partire dal kernel 2.4.21, solo su PowerPC. da \param{arg2}; per i dettagli sul significato dei \textit{securebits} si veda sez.~\ref{sec:proc_capabilities}, ed in particolare i valori di tab.~\ref{tab:securebits_values} e la relativa trattazione. L'operazione - richiede i privilegi di amministratore (la \itindex{capabilities} capacità - \const{CAP\_SETPCAP}), altrimenti la chiamata fallirà con un errore di - \errval{EPERM}. Introdotta a partire dal kernel 2.6.26. + richiede i privilegi di amministratore (la capacità \const{CAP\_SETPCAP}), + altrimenti la chiamata fallirà con un errore di \errval{EPERM}. Introdotta a + partire dal kernel 2.6.26. \item[\const{PR\_GET\_SECUREBITS}] Ottiene come valore di ritorno della funzione l'impostazione corrente per i \itindex{securebits} @@ -3900,6 +3915,16 @@ Introdotta a partire dal kernel 2.4.21, solo su PowerPC. % * Documentation/prctl/seccomp_filter.txt % * http://lwn.net/Articles/475043/ + +% TODO documentare PR_MPX_INIT e PR_MPX_RELEASE, vedi +% http://lwn.net/Articles/582712/ + +% TODO documentare PR_SET_MM_MAP aggiunta con il kernel 3.18, per impostare i +% parametri di base del layout dello spazio di indirizzi di un processo (area +% codice e dati, stack, brack pointer ecc. vedi +% http://git.kernel.org/linus/f606b77f1a9e362451aca8f81d8f36a3a112139e + + \label{sec:prctl_operation} \end{basedescript} @@ -4067,7 +4092,7 @@ elenco, che illustra quelle attualmente disponibili:\footnote{si fa chiusura o cambiamento dei \textit{file descriptor flag} di un \textit{file descriptor} verrà per entrambi. - Se non viene impostato il processo figlio eredita una copia della  + Se non viene impostato il processo figlio eredita una copia della \itindex{file~descriptor~table} \textit{file descriptor table} del padre e vale la semantica classica della gestione dei \textit{file descriptor}, che costituisce il comportamento ordinario di un sistema unix-like e che @@ -4097,8 +4122,11 @@ elenco, che illustra quelle attualmente disponibili:\footnote{si fa \end{basedescript} -%TODO trattare unshare +%TODO trattare unshare, vedi anche http://lwn.net/Articles/532748/ + +%TODO trattare kcmp aggiunta con il kernel 3.5, vedi +% https://lwn.net/Articles/478111/ \subsection{La funzione \func{ptrace}} \label{sec:process_ptrace} @@ -4106,6 +4134,11 @@ elenco, che illustra quelle attualmente disponibili:\footnote{si fa Da fare % TODO: trattare PTRACE_SEIZE, aggiunta con il kernel 3.1 +% TODO: trattare PTRACE_O_EXITKILL, aggiunta con il kernel 3.8 (vedi +% http://lwn.net/Articles/529060/) +% TODO: trattare PTRACE_GETSIGMASK e PTRACE_SETSIGMASK introdotte con il +% kernel 3.11 + \subsection{La gestione delle operazioni in virgola mobile} @@ -4144,6 +4177,15 @@ Da fare % le pagine di manuale relative % vedere anche dove metterle... +% \subsection{La gestione dei moduli} +% \label{sec:kernel_modules} + +% da fare + +%TODO trattare init_module e finit_module (quest'ultima introdotta con il +%kernel 3.8) + + \section{Problematiche di programmazione multitasking} \label{sec:proc_multi_prog}