From 85590332c245e487cff2b566b2df286acc4289ee Mon Sep 17 00:00:00 2001 From: Simone Piccardi Date: Fri, 6 Jan 2012 21:42:45 +0000 Subject: [PATCH] Sistemata buona parte del capitolo 3. --- fileadv.tex | 2 +- filedir.tex | 94 +- fileunix.tex | 2 +- ipc.tex | 22 +- prochand.tex | 2481 ++++++++++++++++++++++++++------------------------ session.tex | 4 +- signal.tex | 8 +- socket.tex | 6 +- 8 files changed, 1377 insertions(+), 1242 deletions(-) diff --git a/fileadv.tex b/fileadv.tex index 29a6eac..86a0aca 100644 --- a/fileadv.tex +++ b/fileadv.tex @@ -811,7 +811,7 @@ opportune verifiche nei processi, questo verrebbe comunque rispettato. Per poter utilizzare il \textit{mandatory locking} è stato introdotto un utilizzo particolare del bit \itindex{sgid~bit} \acr{sgid}. Se si ricorda quanto esposto in sez.~\ref{sec:file_special_perm}), esso viene di norma -utilizzato per cambiare il group-ID effettivo con cui viene eseguito un +utilizzato per cambiare il \acr{gid} effettivo con cui viene eseguito un programma, ed è pertanto sempre associato alla presenza del permesso di esecuzione per il gruppo. Impostando questo bit su un file senza permesso di esecuzione in un sistema che supporta il \textit{mandatory locking}, fa sì che diff --git a/filedir.tex b/filedir.tex index 6d02656..b3d4e92 100644 --- a/filedir.tex +++ b/filedir.tex @@ -584,7 +584,7 @@ La funzione che permette la cancellazione di una directory è invece \begin{errlist} \item[\errcode{EPERM}] il filesystem non supporta la cancellazione di directory, oppure la directory che contiene \param{dirname} ha lo - \itindex{sticky~bit} \textit{sticky bit} impostato e l'user-ID effettivo + \itindex{sticky~bit} \textit{sticky bit} impostato e l'\acr{uid} effettivo del processo non corrisponde al proprietario della directory. \item[\errcode{EACCES}] non c'è il permesso di scrittura per la directory che contiene la directory che si vuole cancellare, o non c'è il permesso @@ -2355,8 +2355,8 @@ veda sez.~\ref{sec:file_special_perm}). La procedura con cui il kernel stabilisce se un processo possiede un certo permesso (di lettura, scrittura o esecuzione) si basa sul confronto fra l'utente e il gruppo a cui il file appartiene (i valori di \var{st\_uid} e -\var{st\_gid} accennati in precedenza) e l'user-ID effettivo, il group-ID -effettivo e gli eventuali group-ID supplementari del processo.\footnote{in +\var{st\_gid} accennati in precedenza) e l'\acr{uid} effettivo, il \acr{gid} +effettivo e gli eventuali \acr{gid} supplementari del processo.\footnote{in realtà Linux, per quanto riguarda l'accesso ai file, utilizza gli identificatori del gruppo \textit{filesystem} (si ricordi quanto esposto in sez.~\ref{sec:proc_perms}), ma essendo questi del tutto equivalenti ai primi, @@ -2365,19 +2365,19 @@ effettivo e gli eventuali group-ID supplementari del processo.\footnote{in Per una spiegazione dettagliata degli identificatori associati ai processi si veda sez.~\ref{sec:proc_perms}; normalmente, a parte quanto vedremo in -sez.~\ref{sec:file_special_perm}, l'user-ID effettivo e il group-ID effettivo +sez.~\ref{sec:file_special_perm}, l'\acr{uid} effettivo e il \acr{gid} effettivo corrispondono ai valori dell'\acr{uid} e del \acr{gid} dell'utente che ha -lanciato il processo, mentre i group-ID supplementari sono quelli dei gruppi +lanciato il processo, mentre i \acr{gid} supplementari sono quelli dei gruppi cui l'utente appartiene. I passi attraverso i quali viene stabilito se il processo possiede il diritto di accesso sono i seguenti: \begin{enumerate} -\item Se l'user-ID effettivo del processo è zero (corrispondente +\item Se l'\acr{uid} effettivo del processo è zero (corrispondente all'amministratore) l'accesso è sempre garantito senza nessun ulteriore controllo. Per questo motivo \textsl{root} ha piena libertà di accesso a tutti i file. -\item Se l'user-ID effettivo del processo è uguale all'\acr{uid} del +\item Se l'\acr{uid} effettivo del processo è uguale all'\acr{uid} del proprietario del file (nel qual caso si dice che il processo è proprietario del file) allora: \begin{itemize*} @@ -2387,7 +2387,7 @@ di accesso sono i seguenti: impostato, l'accesso è consentito \item altrimenti l'accesso è negato \end{itemize*} -\item Se il group-ID effettivo del processo o uno dei group-ID supplementari +\item Se il \acr{gid} effettivo del processo o uno dei \acr{gid} supplementari dei processi corrispondono al \acr{gid} del file allora: \begin{itemize*} \item se il bit dei permessi d'accesso del gruppo è impostato, l'accesso è @@ -2429,9 +2429,9 @@ corrispondono a quelli dell'utente con cui si è entrati nel sistema. Se però il file del programma (che ovviamente deve essere eseguibile\footnote{per motivi di sicurezza il kernel ignora i bit \acr{suid} e \acr{sgid} per gli script eseguibili.}) ha il bit \acr{suid} impostato, il -kernel assegnerà come user-ID effettivo al nuovo processo l'\acr{uid} del +kernel assegnerà come \acr{uid} effettivo al nuovo processo l'\acr{uid} del proprietario del file al posto dell'\acr{uid} del processo originario. Avere -il bit \acr{sgid} impostato ha lo stesso effetto sul group-ID effettivo del +il bit \acr{sgid} impostato ha lo stesso effetto sul \acr{gid} effettivo del processo. I bit \acr{suid} e \acr{sgid} vengono usati per permettere agli utenti normali @@ -2528,9 +2528,9 @@ consapevolmente, cancellare i file temporanei creati degli altri utenti. \label{sec:file_perm_management} Come visto in sez.~\ref{sec:file_access_control} il controllo di accesso ad un -file viene fatto utilizzando l'user-ID ed il group-ID effettivo del processo; -ci sono casi però in cui si può voler effettuare il controllo con l'user-ID -reale ed il group-ID reale, vale a dire usando i valori di \acr{uid} e +file viene fatto utilizzando l'\acr{uid} ed il \acr{gid} effettivo del processo; +ci sono casi però in cui si può voler effettuare il controllo con l'\acr{uid} +reale ed il \acr{gid} reale, vale a dire usando i valori di \acr{uid} e \acr{gid} relativi all'utente che ha lanciato il programma, e che, come accennato in sez.~\ref{sec:file_special_perm} e spiegato in dettaglio in sez.~\ref{sec:proc_perms}, non è detto siano uguali a quelli effettivi. @@ -2621,7 +2621,7 @@ filename e su un file descriptor, i loro prototipi sono: \bodydesc{Le funzioni restituiscono zero in caso di successo e -1 per un errore, in caso di errore \var{errno} può assumere i valori: \begin{errlist} - \item[\errcode{EPERM}] l'user-ID effettivo non corrisponde a quello del + \item[\errcode{EPERM}] l'\acr{uid} effettivo non corrisponde a quello del proprietario del file o non è zero. \item[\errcode{EROFS}] il file è su un filesystem in sola lettura. \end{errlist} @@ -2685,7 +2685,7 @@ bit \itindex{suid~bit} \acr{suid} il valore da fornire sarebbe $4755$. Il cambiamento dei permessi di un file eseguito attraverso queste funzioni ha comunque alcune limitazioni, previste per motivi di sicurezza. L'uso delle -funzioni infatti è possibile solo se l'user-ID effettivo del processo +funzioni infatti è possibile solo se l'\acr{uid} effettivo del processo corrisponde a quello del proprietario del file o dell'amministratore, altrimenti esse falliranno con un errore di \errcode{EPERM}. @@ -2695,7 +2695,7 @@ non tutti i valori possibili di \param{mode} sono permessi o hanno effetto; in particolare accade che: \begin{enumerate} \item siccome solo l'amministratore può impostare lo \itindex{sticky~bit} - \textit{sticky bit}, se l'user-ID effettivo del processo non è zero esso + \textit{sticky bit}, se l'\acr{uid} effettivo del processo non è zero esso viene automaticamente cancellato (senza notifica di errore) qualora sia stato indicato in \param{mode}. \item per quanto detto in sez.~\ref{sec:file_ownership_management} riguardo la @@ -2705,7 +2705,7 @@ in particolare accade che: un file appartenente ad un gruppo per cui non si hanno diritti, questo viene automaticamente cancellato da \param{mode} (senza notifica di errore) qualora il gruppo del file non corrisponda a quelli associati al processo - (la cosa non avviene quando l'user-ID effettivo del processo è zero). + (la cosa non avviene quando l'\acr{uid} effettivo del processo è zero). \end{enumerate} Per alcuni filesystem\footnote{i filesystem più comuni (\textsl{ext2}, @@ -2779,10 +2779,10 @@ per la creazione di nuove directory (procedimento descritto in sez.~\ref{sec:file_dir_creat_rem}). Lo standard POSIX prescrive che l'\acr{uid} del nuovo file corrisponda -all'user-ID effettivo del processo che lo crea; per il \acr{gid} invece prevede +all'\acr{uid} effettivo del processo che lo crea; per il \acr{gid} invece prevede due diverse possibilità: \begin{itemize*} -\item il \acr{gid} del file corrisponde al group-ID effettivo del processo. +\item il \acr{gid} del file corrisponde al \acr{gid} effettivo del processo. \item il \acr{gid} del file corrisponde al \acr{gid} della directory in cui esso è creato. \end{itemize*} @@ -2833,7 +2833,7 @@ l'utente che il gruppo a cui un file appartiene; i rispettivi prototipi sono: \bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 per un errore, nel qual caso caso \var{errno} assumerà i valori: \begin{errlist} - \item[\errcode{EPERM}] l'user-ID effettivo non corrisponde a quello del + \item[\errcode{EPERM}] l'\acr{uid} effettivo non corrisponde a quello del proprietario del file o non è zero, o utente e gruppo non sono validi \end{errlist} Oltre a questi entrambe restituiscono gli errori \errval{EROFS} e @@ -3544,15 +3544,15 @@ identificatori del gruppo \textit{effective} del processo, ma in presenza di ACL i passi attraverso i quali viene stabilito se esso ha diritto di accesso sono i seguenti: \begin{enumerate*} -\item Se l'user-ID del processo è nullo l'accesso è sempre garantito senza +\item Se l'\acr{uid} del processo è nullo l'accesso è sempre garantito senza nessun controllo. -\item Se l'user-ID del processo corrisponde al proprietario del file allora: +\item Se l'\acr{uid} del processo corrisponde al proprietario del file allora: \begin{itemize*} \item se la voce \const{ACL\_USER\_OBJ} contiene il permesso richiesto, l'accesso è consentito; \item altrimenti l'accesso è negato. \end{itemize*} -\item Se l'user-ID del processo corrisponde ad un qualunque qualificatore +\item Se l'\acr{uid} del processo corrisponde ad un qualunque qualificatore presente in una voce \const{ACL\_USER} allora: \begin{itemize*} \item se la voce \const{ACL\_USER} corrispondente e la voce @@ -3560,7 +3560,7 @@ sono i seguenti: consentito; \item altrimenti l'accesso è negato. \end{itemize*} -\item Se è il group-ID del processo o uno dei group-ID supplementari +\item Se è il \acr{gid} del processo o uno dei \acr{gid} supplementari corrisponde al gruppo proprietario del file allora: \begin{itemize*} \item se la voce \const{ACL\_GROUP\_OBJ} e una eventuale voce @@ -3569,7 +3569,7 @@ sono i seguenti: l'accesso è consentito; \item altrimenti l'accesso è negato. \end{itemize*} -\item Se è il group-ID del processo o uno dei group-ID supplementari +\item Se è il \acr{gid} del processo o uno dei \acr{gid} supplementari corrisponde ad un qualunque qualificatore presente in una voce \const{ACL\_GROUP} allora: \begin{itemize*} @@ -3913,7 +3913,7 @@ tab.~\ref{tab:acl_to_text_options}. \hline \const{TEXT\_ABBREVIATE} & stampa le voci in forma abbreviata.\\ \const{TEXT\_NUMERIC\_IDS} & non effettua la risoluzione numerica di - user-ID e group-ID.\\ + \acr{uid} e \acr{gid}.\\ \const{TEXT\_SOME\_EFFECTIVE}& per ciascuna voce che contiene permessi che vengono eliminati dalla \const{ACL\_MASK} viene generato un commento con i permessi @@ -4819,7 +4819,7 @@ nell'esecuzione di un qualunque programma l'amministratore perderebbe tutti i privilegi originali dal processo. Per questo motivo se un programma senza \textit{capabilities} assegnate viene -eseguito da un processo con \textit{real user-ID} 0, esso verrà trattato come +eseguito da un processo con \acr{uid} reale 0, esso verrà trattato come se tanto il \textit{permitted set} che l'\textit{inheritable set} fossero con tutte le \textit{capabilities} abilitate, con l'\textit{effective set} attivo, col risultato di fornire comunque al processo tutte le capacità presenti nel @@ -4828,19 +4828,19 @@ il \acr{suid} bit ed appartiene all'amministratore, in entrambi i casi si riesce così a riottenere il comportamento classico di un sistema unix-like. Una seconda circostanza è quella relativa a cosa succede alle -\textit{capabilities} di un processo nelle possibili transizioni da -\textit{user-ID} nullo a \textit{user-ID} non nullo o viceversa (corrispondenti -rispettivamente a cedere o riottenere i i privilegi di amministratore) che si -possono effettuare con le varie funzioni viste in -sez.~\ref{sec:proc_setuid}. In questo caso la casistica è di nuovo alquanto -complessa, considerata anche la presenza dei diversi gruppi di identificatori -illustrati in tab.~\ref{tab:proc_uid_gid}, si avrà allora che: +\textit{capabilities} di un processo nelle possibili transizioni da \acr{uid} +nullo a \acr{uid} non nullo o viceversa (corrispondenti rispettivamente a +cedere o riottenere i i privilegi di amministratore) che si possono effettuare +con le varie funzioni viste in sez.~\ref{sec:proc_setuid}. In questo caso la +casistica è di nuovo alquanto complessa, considerata anche la presenza dei +diversi gruppi di identificatori illustrati in tab.~\ref{tab:proc_uid_gid}, si +avrà allora che: \begin{enumerate*} -\item se si passa da \textit{effective user-ID} nullo a non nullo +\item se si passa da \acr{uid} effettivo nullo a non nullo l'\textit{effective set} del processo viene totalmente azzerato, se - viceversa si passa da \textit{effective user-ID} non nullo a nullo il + viceversa si passa da \acr{uid} effettivo non nullo a nullo il \textit{permitted set} viene copiato nell'\textit{effective set}; -\item se si passa da \textit{file system user-ID} nullo a non nullo verranno +\item se si passa da \textit{file system} \acr{uid} nullo a non nullo verranno cancellate dall'\textit{effective set} del processo tutte le capacità attinenti i file, e cioè \const{CAP\_LINUX\_IMMUTABLE}, \const{CAP\_MKNOD}, \const{CAP\_DAC\_OVERRIDE}, \const{CAP\_DAC\_READ\_SEARCH}, @@ -4875,7 +4875,7 @@ Per questo motivo a partire dal kernel 2.6.26, se le \textit{file ulteriore maschera binaria, chiamata \textit{securebits flags}, su cui sono mantenuti una serie di flag (vedi tab.~\ref{tab:securebits_values}) il cui valore consente di modificare queste regole speciali che si applicano ai -processi con \textit{user-ID} nullo. La maschera viene sempre mantenuta +processi con \acr{uid} nullo. La maschera viene sempre mantenuta attraverso una \func{fork}, mentre attraverso una \func{exec} viene sempre cancellato il flag \const{SECURE\_KEEP\_CAPS}. @@ -4889,22 +4889,22 @@ cancellato il flag \const{SECURE\_KEEP\_CAPS}. \hline \const{SECURE\_KEEP\_CAPS}& Il processo non subisce la cancellazione delle sue \textit{capabilities} quando tutti i suoi - \textit{user-ID} passano ad un valore non + \acr{uid} passano ad un valore non nullo (regola di compatibilità per il cambio - di \textit{user-ID} n. 3 del precedente + di \acr{uid} n.~3 del precedente elenco), sostituisce il precedente uso dell'operazione \const{PR\_SET\_KEEPCAPS} di \func{prctl}.\\ \const{SECURE\_NO\_SETUID\_FIXUP}&Il processo non subisce le modifiche delle sue \textit{capabilities} nel passaggio - da nullo a non nullo degli \textit{user-ID} + da nullo a non nullo degli \acr{uid} dei gruppi \textit{effective} e \textit{file system} (regole di compatibilità - per il cambio di \textit{user-ID} nn. 1 e 2 del + per il cambio di \acr{uid} nn.~1 e 2 del precedente elenco).\\ \const{SECURE\_NOROOT} & Il processo non assume nessuna capacità aggiuntiva quando esegue un programma, anche - se ha \textit{user-ID} nullo o il programma ha + se ha \acr{uid} nullo o il programma ha il \acr{suid} bit attivo ed appartiene all'amministratore (regola di compatibilità per l'esecuzione di programmi senza @@ -5140,8 +5140,8 @@ capacità), o di impostare i \textit{securebits} delle \textit{capabilities}. La prima fra le capacità ``\textsl{ampie}'' che occorre dettagliare maggiormente è \const{CAP\_FOWNER}, che rimuove le restrizioni poste ad un processo che non ha la proprietà di un file in un vasto campo di -operazioni;\footnote{vale a dire la richiesta che l'user-ID effettivo del - processo (o meglio il \textit{filesystem user-ID}, vedi +operazioni;\footnote{vale a dire la richiesta che l'\acr{uid} effettivo del + processo (o meglio l'\acr{uid} di filesystem, vedi sez.~\ref{sec:proc_setuid}) coincida con quello del proprietario.} queste comprendono i cambiamenti dei permessi e dei tempi del file (vedi sez.~\ref{sec:file_perm_management} e sez.~\ref{sec:file_file_times}), le @@ -5166,7 +5166,7 @@ disattivare la swap, montare, rimontare e smontare filesystem (vedi sez.~\ref{sec:sys_file_config}), effettuare operazioni di controllo su qualunque oggetto dell'IPC di SysV (vedi sez.~\ref{sec:ipc_sysv}), operare sugli attributi estesi dei file di classe \texttt{security} o \texttt{trusted} -(vedi sez.~\ref{sec:file_xattr}), specificare un \textit{user-ID} arbitrario +(vedi sez.~\ref{sec:file_xattr}), specificare un \acr{uid} arbitrario nella trasmissione delle credenziali dei socket (vedi sez.~\ref{sec:socket_credential_xxx}), assegnare classi privilegiate (\const{IOPRIO\_CLASS\_RT} e prima del kernel 2.6.25 anche @@ -5835,7 +5835,7 @@ con la funzione \funcd{chroot}, il cui prototipo è: \bodydesc{La funzione restituisce zero in caso di successo e -1 per un errore, in caso di errore \var{errno} può assumere i valori: \begin{errlist} - \item[\errcode{EPERM}] l'user-ID effettivo del processo non è zero. + \item[\errcode{EPERM}] l'\acr{uid} effettivo del processo non è zero. \end{errlist} ed inoltre \errval{EFAULT}, \errval{ENAMETOOLONG}, \errval{ENOENT}, \errval{ENOMEM}, \errval{ENOTDIR}, \errval{EACCES}, \errval{ELOOP}; diff --git a/fileunix.tex b/fileunix.tex index bdef736..dad3b0f 100644 --- a/fileunix.tex +++ b/fileunix.tex @@ -1329,7 +1329,7 @@ il comportamento rispetto a quello ordinario di \func{access}. In questo caso esso può essere specificato come maschera binaria di due valori: \begin{basedescript}{\desclabelwidth{3.0cm}} \item[\const{AT\_EACCESS}] se impostato \funcd{faccessat} esegue il controllo - dei permessi usando l'\textsl{user-ID effettivo} invece di quello reale (il + dei permessi usando l'\acr{uid} effettivo invece di quello reale (il comportamento di default, che riprende quello di \func{access}). \item[\const{AT\_SYMLINK\_NOFOLLOW}] se impostato \funcd{faccessat} non esegue la dereferenziazione dei link simbolici, effettuando il controllo dei diff --git a/ipc.tex b/ipc.tex index 742846d..5841c54 100644 --- a/ipc.tex +++ b/ipc.tex @@ -947,7 +947,7 @@ il proprietario, il suo gruppo e tutti gli altri. Quando l'oggetto viene creato i campi \var{cuid} e \var{uid} di \struct{ipc\_perm} ed i campi \var{cgid} e \var{gid} vengono impostati -rispettivamente al valore dell'user-ID e del group-ID effettivo del processo +rispettivamente al valore dell'\acr{uid} e del \acr{gid} effettivo del processo che ha chiamato la funzione, ma, mentre i campi \var{uid} e \var{gid} possono essere cambiati, i campi \var{cuid} e \var{cgid} restano sempre gli stessi. @@ -967,12 +967,12 @@ controlli è simile a quello dei file, ed avviene secondo questa sequenza: \begin{itemize*} \item se il processo ha i privilegi di amministratore l'accesso è sempre consentito. -\item se l'user-ID effettivo del processo corrisponde o al valore del campo +\item se l'\acr{uid} effettivo del processo corrisponde o al valore del campo \var{cuid} o a quello del campo \var{uid} ed il permesso per il proprietario in \var{mode} è appropriato\footnote{per appropriato si intende che è impostato il permesso di scrittura per le operazioni di scrittura e quello di lettura per le operazioni di lettura.} l'accesso è consentito. -\item se il group-ID effettivo del processo corrisponde o al +\item se il \acr{gid} effettivo del processo corrisponde o al valore del campo \var{cgid} o a quello del campo \var{gid} ed il permesso per il gruppo in \var{mode} è appropriato l'accesso è consentito. \item se il permesso per gli altri è appropriato l'accesso è consentito. @@ -1303,7 +1303,7 @@ eseguire; i valori possibili sono: riceveranno un errore di \errcode{EIDRM}, e tutti processi in attesa su funzioni di lettura o di scrittura sulla coda saranno svegliati ricevendo il medesimo errore. Questo comando può essere eseguito solo da un processo - con user-ID effettivo corrispondente al creatore o al proprietario della + con \acr{uid} effettivo corrispondente al creatore o al proprietario della coda, o all'amministratore. \item[\const{IPC\_SET}] Permette di modificare i permessi ed il proprietario della coda, ed il limite massimo sulle dimensioni del totale dei messaggi in @@ -1957,14 +1957,14 @@ seguenti: \item[\const{IPC\_RMID}] Rimuove l'insieme di semafori e le relative strutture dati, con effetto immediato. Tutti i processi che erano stato di \textit{sleep} vengono svegliati, ritornando con un errore di - \errcode{EIDRM}. L'user-ID effettivo del processo deve corrispondere o al + \errcode{EIDRM}. L'\acr{uid} effettivo del processo deve corrispondere o al creatore o al proprietario dell'insieme, o all'amministratore. L'argomento \param{semnum} viene ignorato. \item[\const{IPC\_SET}] Permette di modificare i permessi ed il proprietario dell'insieme. I valori devono essere passati in una struttura \struct{semid\_ds} puntata da \param{arg.buf} di cui saranno usati soltanto i campi \var{sem\_perm.uid}, \var{sem\_perm.gid} e i nove bit meno - significativi di \var{sem\_perm.mode}. L'user-ID effettivo del processo deve + significativi di \var{sem\_perm.mode}. L'\acr{uid} effettivo del processo deve corrispondere o al creatore o al proprietario dell'insieme, o all'amministratore. L'argomento \param{semnum} viene ignorato. \item[\const{GETALL}] Restituisce il valore corrente di ciascun semaforo @@ -2485,7 +2485,7 @@ un segmento di memoria condivisa è \funcd{shmctl}; il suo prototipo è: \item[\errcode{EPERM}] si è specificato un comando con \const{IPC\_SET} o \const{IPC\_RMID} senza i permessi necessari. \item[\errcode{EOVERFLOW}] si è tentato il comando \const{IPC\_STAT} ma il - valore del group-ID o dell'user-ID è troppo grande per essere + valore del \acr{gid} o dell'\acr{uid} è troppo grande per essere memorizzato nella struttura puntata da \param{buf}. \item[\errcode{EFAULT}] l'indirizzo specificato con \param{buf} non è valido. @@ -2504,7 +2504,7 @@ corrispondente comportamento della funzione, sono i seguenti: \item[\const{IPC\_RMID}] Marca il segmento di memoria condivisa per la rimozione, questo verrà cancellato effettivamente solo quando l'ultimo processo ad esso agganciato si sarà staccato. Questo comando può essere - eseguito solo da un processo con user-ID effettivo corrispondente o al + eseguito solo da un processo con \acr{uid} effettivo corrispondente o al creatore del segmento, o al proprietario del segmento, o all'amministratore. \item[\const{IPC\_SET}] Permette di modificare i permessi ed il proprietario del segmento. Per modificare i valori di \var{shm\_perm.mode}, @@ -3324,7 +3324,7 @@ quella particolare (si ricordi quanto visto in sez.~\ref{sec:ipc_sysv_access_control}) che viene usata per gli oggetti del SysV IPC. Per quanto riguarda l'attribuzione dell'utente e del gruppo proprietari dell'oggetto alla creazione di quest'ultimo essa viene effettuata -secondo la semantica SysV: corrispondono cioè a user-ID e group-ID effettivi +secondo la semantica SysV: corrispondono cioè a \acr{uid} e \acr{gid} effettivi del processo che esegue la creazione. @@ -4055,8 +4055,8 @@ presente che, come accennato in sez.~\ref{sec:ipc_posix_generic}, i semafori usano la semantica standard dei file per quanto riguarda i controlli di accesso. -Questo significa che un nuovo semaforo viene sempre creato con l'user-ID ed il -group-ID effettivo del processo chiamante, e che i permessi indicati con +Questo significa che un nuovo semaforo viene sempre creato con l'\acr{uid} ed il +\acr{gid} effettivo del processo chiamante, e che i permessi indicati con \param{mode} vengono filtrati dal valore della \itindex{umask} \textit{umask} del processo. Inoltre per poter aprire un semaforo è necessario avere su di esso sia il permesso di lettura che quello di scrittura. diff --git a/prochand.tex b/prochand.tex index ba788ae..1683f0a 100644 --- a/prochand.tex +++ b/prochand.tex @@ -434,12 +434,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} 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} \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 @@ -557,8 +557,8 @@ Quello che succede è che quando lo \textit{standard output}\footnote{si chiama l'argomento in dettaglio in sez.~\ref{sec:file_std_descr}.} 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 file descriptor (vedi sez.~\ref{sec:file_fd}) dei file -aperti nel processo padre (allo stesso modo in cui lo fa la funzione +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 dettagli questi termini in @@ -626,8 +626,8 @@ comune dopo l'esecuzione di una \func{fork} è la seguente: sez.~\ref{sec:proc_real_time} e sez.~\ref{sec:proc_sched_multiprocess}); \item le variabili di ambiente (vedi sez.~\ref{sec:proc_environ}). \item l'insieme dei descrittori associati alle code di messaggi POSIX (vedi - sez.~\ref{sec:ipc_posix_mq}) che vengono copiate come i file descriptor, - questo significa che entrambi condivideranno gli stessi flag. + sez.~\ref{sec:ipc_posix_mq}) che vengono copiate come i \textit{file + descriptor}, questo significa che entrambi condivideranno gli stessi flag. \end{itemize*} Oltre a quelle relative ad un diverso spazio degli indirizzi (e una memoria @@ -715,7 +715,8 @@ comunque una serie di operazioni di terminazione: chiude tutti i file aperti, rilascia la memoria che stava usando, e così via; l'elenco completo delle operazioni eseguite alla chiusura di un processo è il seguente: \begin{itemize*} -\item tutti i file descriptor sono chiusi; +\item tutti i \textit{file descriptor} (vedi sez.~\ref{sec:file_fd}) sono + chiusi; \item viene memorizzato lo stato di terminazione del processo; \item ad ogni processo figlio viene assegnato un nuovo padre (in genere \cmd{init}); @@ -824,7 +825,7 @@ 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 il padre effettuerà la lettura dello stato di terminazione anche questa informazione, non più necessaria, verrà scartata ed il processo potrà -considerarso completamente concluso. +considerarsi completamente concluso. Possiamo utilizzare il nostro programma di prova per analizzare anche questa condizione: lanciamo il comando \cmd{forktest} in \textit{background} (vedi @@ -972,7 +973,7 @@ La prima differenza fra le due funzioni è che con \func{waitpid} si può specificare in maniera flessibile quale processo attendere, sulla base del valore fornito dall'argomento \param{pid}, questo può assumere diversi valori, secondo lo specchietto riportato in tab.~\ref{tab:proc_waidpid_pid}, dove si -sono riportate anche le costanti definite per indicare alcuni di essi. +sono riportate anche le costanti definite per indicare alcuni di essi. \begin{table}[!htb] \centering @@ -985,14 +986,14 @@ sono riportate anche le costanti definite per indicare alcuni di essi. $<-1$& -- & Attende per un figlio il cui \itindex{process~group} \textit{process group} (vedi sez.~\ref{sec:sess_proc_group}) è uguale - al valore assoluto di \param{pid}. \\ + al valore assoluto di \param{pid}.\\ $-1$&\const{WAIT\_ANY} & Attende per un figlio qualsiasi, usata in questa maniera senza specificare nessuna opzione è equivalente a \func{wait}.\\ $ 0$&\const{WAIT\_MYPGRP}&Attende per un figlio il cui \itindex{process~group} \textit{process group} (vedi sez.~\ref{sec:sess_proc_group}) è - uguale a quello del processo chiamante. \\ + uguale a quello del processo chiamante.\\ $>0$& -- & Attende per un figlio il cui \acr{pid} è uguale al valore di \param{pid}.\\ \hline @@ -1007,34 +1008,45 @@ funzione delle opportune opzioni tramite l'argomento \param{options}; questo deve essere specificato come maschera binaria delle costanti riportati nella prima parte in tab.~\ref{tab:proc_waitpid_options} che possono essere combinate fra loro con un OR aritmetico. Nella seconda parte della stessa -tabella si sono riportati anche alcuni valori non standard specifici di Linux, -che consentono un controllo più dettagliato per i processi creati con la -\textit{system call} generica \func{clone} (vedi sez.~\ref{sec:process_clone}) -usati principalmente per la gestione della terminazione dei \itindex{thread} -\textit{thread} (vedi sez.~\ref{sec:thread_xxx}). +tabella si sono riportati anche alcune opzioni non standard specifiche di +Linux, che consentono un controllo più dettagliato per i processi creati con +la \textit{system call} generica \func{clone} (vedi +sez.~\ref{sec:process_clone}) e che vengono usati principalmente per la +gestione della terminazione dei \itindex{thread} \textit{thread} (vedi +sez.~\ref{sec:thread_xxx}). \begin{table}[!htb] \centering \footnotesize \begin{tabular}[c]{|l|p{8cm}|} \hline - \textbf{Valore} & \textbf{Descrizione}\\ + \textbf{Costante} & \textbf{Descrizione}\\ \hline \hline \const{WNOHANG} & La funzione ritorna immediatamente anche se non è - terminato nessun processo figlio. \\ - \const{WUNTRACED} & Ritorna anche se un processo figlio è stato fermato. \\ + terminato nessun processo figlio.\\ + \const{WUNTRACED} & Ritorna anche quando un processo figlio è stato + fermato.\\ \const{WCONTINUED}& Ritorna anche quando un processo figlio che era stato - fermato ha ripreso l'esecuzione.\footnotemark \\ + fermato ha ripreso l'esecuzione (disponibile solo a + partire dal kernel 2.6.10).\\ \hline \const{\_\_WCLONE}& Attende solo per i figli creati con \func{clone} (vedi sez.~\ref{sec:process_clone}), vale a dire processi che non emettono nessun segnale o emettono un segnale diverso da \signal{SIGCHLD} alla - terminazione. \\ - \const{\_\_WALL} & Attende per qualunque processo figlio. \\ + terminazione, il default è attendere soltanto i + processi figli ordinari ignorando quelli creati da + \func{clone}.\\ + \const{\_\_WALL} & Attende per qualunque figlio, sia ordinario che creato + con \func{clone}, se specificata insieme a + \const{\_\_WCLONE} quest'ultima viene ignorata. \\ \const{\_\_WNOTHREAD}& Non attende per i figli di altri \textit{thread} - dello stesso gruppo. \\ + dello stesso \textit{thread group}, questo era il + comportamento di default del kernel 2.4 che non + supportava la possibilità, divenuta il default a + partire dal 2.6, di attendere un qualunque figlio + appartenente allo stesso \textit{thread group}. \\ \hline \end{tabular} \caption{Costanti che identificano i bit dell'argomento \param{options} @@ -1042,16 +1054,14 @@ usati principalmente per la gestione della terminazione dei \itindex{thread} \label{tab:proc_waitpid_options} \end{table} -\footnotetext{disponibile solo a partire dal kernel 2.6.10.} L'uso dell'opzione \const{WNOHANG} consente di prevenire il blocco della -funzione qualora nessun figlio sia uscito (o non si siano verificate le altre -condizioni per l'uscita della funzione); in tal caso la funzione ritornerà un -valore nullo anziché positivo.\footnote{anche in questo caso un valore - positivo indicherà il \acr{pid} del processo di cui si è ricevuto lo stato - ed un valore negativo un errore.} +funzione qualora nessun figlio sia uscito o non si siano verificate le altre +condizioni per l'uscita della funzione. in tal caso. In tal caso la funzione, +invece di restituire il \acr{pid} del processo (che è sempre un intero +positivo) ritornerà un valore nullo. -Le altre due opzioni \const{WUNTRACED} e \const{WCONTINUED} consentono +Le altre due opzioni, \const{WUNTRACED} e \const{WCONTINUED}, consentono rispettivamente di tracciare non la terminazione di un processo, ma il fatto che esso sia stato fermato, o fatto ripartire, e sono utilizzate per la gestione del controllo di sessione (vedi sez.~\ref{sec:sess_job_control}). @@ -1065,7 +1075,7 @@ quando un processo figlio entra nello stato \textit{stopped}\footnote{in mentre con \const{WCONTINUED} la funzione ritorna quando un processo in stato \textit{stopped} riprende l'esecuzione per la ricezione del segnale \signal{SIGCONT} (l'uso di questi segnali per il controllo di sessione è -dettagliato in sez.~\ref{sec:sess_ctrl_term}). +trattato in sez.~\ref{sec:sess_ctrl_term}). La terminazione di un processo figlio (così come gli altri eventi osservabili con \func{waitpid}) è chiaramente un evento asincrono rispetto all'esecuzione @@ -1079,26 +1089,46 @@ kernel avverte il processo padre che uno dei suoi figli è terminato. Il comportamento delle funzioni è però cambiato nel passaggio dal kernel 2.4 al kernel 2.6, quest'ultimo infatti si è adeguato alle prescrizioni dello -standard POSIX.1-2001,\footnote{una revisione del 2001 dello standard POSIX.1 - che ha aggiunto dei requisiti e delle nuove funzioni, come \func{waitid}.} -e come da esso richiesto se \signal{SIGCHLD} viene ignorato, o se si imposta il -flag di \const{SA\_NOCLDSTOP} nella ricezione dello stesso (si veda -sez.~\ref{sec:sig_sigaction}) i processi figli che terminano non diventano -\textit{zombie} e sia \func{wait} che \func{waitpid} si bloccano fintanto che -tutti i processi figli non sono terminati, dopo di che falliscono con un -errore di \errcode{ENOCHLD}.\footnote{questo è anche il motivo per cui le - opzioni \const{WUNTRACED} e \const{WCONTINUED} sono utilizzabili soltanto - qualora non si sia impostato il flag di \const{SA\_NOCLDSTOP} per il segnale - \signal{SIGCHLD}.} +standard POSIX.1-2001 e come da esso richiesto se \signal{SIGCHLD} viene +ignorato, o se si imposta il flag di \const{SA\_NOCLDSTOP} nella ricezione +dello stesso (si veda sez.~\ref{sec:sig_sigaction}) i processi figli che +terminano non diventano \textit{zombie} e sia \func{wait} che \func{waitpid} +si bloccano fintanto che tutti i processi figli non sono terminati, dopo di +che falliscono con un errore di \errcode{ENOCHLD}.\footnote{questo è anche il + motivo per cui le opzioni \const{WUNTRACED} e \const{WCONTINUED} sono + utilizzabili soltanto qualora non si sia impostato il flag di + \const{SA\_NOCLDSTOP} per il segnale \signal{SIGCHLD}.} Con i kernel della serie 2.4 e tutti i kernel delle serie precedenti entrambe -le funzioni di attesa ignorano questa prescrizione\footnote{lo standard POSIX.1 - originale infatti lascia indefinito il comportamento di queste funzioni - quando \signal{SIGCHLD} viene ignorato.} e si comportano sempre nello stesso -modo, indipendentemente dal fatto \signal{SIGCHLD} sia ignorato o meno: +le funzioni di attesa ignorano questa prescrizione e si comportano sempre +nello stesso modo,\footnote{lo standard POSIX.1 originale infatti lascia + indefinito il comportamento di queste funzioni quando \signal{SIGCHLD} viene + ignorato.} indipendentemente dal fatto \signal{SIGCHLD} sia ignorato o meno: attendono la terminazione di un processo figlio e ritornano il relativo \acr{pid} e lo stato di terminazione nell'argomento \param{status}. +In generale in un programma non si vuole essere forzati ad attendere la +conclusione di un processo figlio per proseguire l'esecuzione, specie se tutto +questo serve solo per leggerne lo stato di chiusura (ed evitare eventualmente +la presenza di \itindex{zombie} \textit{zombie}). Per questo la modalità più +comune di chiamare queste funzioni è quella di utilizzarle all'interno di un +\textit{signal handler} (vedremo un esempio di come gestire \signal{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{waitpid} non si bloccherà. + +Come accennato sia \func{wait} che \func{waitpid} restituiscono lo stato di +terminazione del processo tramite il puntatore \param{status}, e se non +interessa memorizzare lo stato si può passare un puntatore nullo. Il valore +restituito da entrambe le funzioni dipende dall'implementazione, ma +tradizionalmente gli 8 bit meno significativi sono riservati per memorizzare +lo \itindex{exit~status} stato di uscita del processo, e gli 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 si possono trovare in + \file{} ma questo file non deve mai essere usato + direttamente, esso viene incluso attraverso \file{}.} + \begin{table}[!htb] \centering \footnotesize @@ -1137,8 +1167,8 @@ attendono la terminazione di un processo figlio e ritornano il relativo \val{WIFSTOPPED} ha restituito un valore non nullo. \\ \macro{WIFCONTINUED(s)}& Vera se il processo che ha causato il ritorno è - stato riavviato da un - \signal{SIGCONT}.\footnotemark \\ + stato riavviato da un \signal{SIGCONT} + (disponibile solo a partire dal kernel 2.6.10).\\ \hline \end{tabular} \caption{Descrizione delle varie macro di preprocessore utilizzabili per @@ -1146,39 +1176,14 @@ attendono la terminazione di un processo figlio e ritornano il relativo \label{tab:proc_status_macro} \end{table} -\footnotetext[20]{questa macro non è definita dallo standard POSIX.1-2001, ma è +\footnotetext{questa macro non è definita dallo standard POSIX.1-2001, ma è presente come estensione sia in Linux che in altri Unix, deve essere pertanto utilizzata con attenzione (ad esempio è il caso di usarla in un blocco \texttt{\#ifdef WCOREDUMP ... \#endif}.} -\footnotetext{è presente solo a partire dal kernel 2.6.10.} - -In generale in un programma non si vuole essere forzati ad attendere la -conclusione di un processo figlio per proseguire l'esecuzione, specie se tutto -questo serve solo per leggerne lo stato di chiusura (ed evitare eventualmente -la presenza di \itindex{zombie} \textit{zombie}). - -Per questo la modalità più comune di chiamare queste funzioni è quella di -utilizzarle all'interno di un \textit{signal handler} (vedremo un esempio di -come gestire \signal{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{waitpid} non si bloccherà. - -Come accennato sia \func{wait} che \func{waitpid} restituiscono lo stato di -terminazione del processo tramite il puntatore \param{status} (se non -interessa memorizzare lo stato si può passare un puntatore nullo). Il valore -restituito da entrambe le funzioni dipende dall'implementazione, ma -tradizionalmente alcuni 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 si possono trovare in \file{} ma - questo file non deve mai essere usato direttamente, esso viene incluso - attraverso \file{}.} - Lo standard POSIX.1 definisce una serie di macro di preprocessore da usare per analizzare lo stato di uscita. Esse sono definite sempre in -\file{} ed elencate in tab.~\ref{tab:proc_status_macro}; si tenga +\file{} ed elencate in tab.~\ref{tab:proc_status_macro}. Si tenga presente che queste macro prevedono che gli si passi come parametro la variabile di tipo \ctyp{int} puntata dall'argomento \param{status} restituito da \func{wait} o \func{waitpid}. @@ -1316,72 +1321,74 @@ precedenti ma che prevedono un ulteriore argomento attraverso il quale il kernel può restituire al padre informazioni sulle risorse (vedi sez.~\ref{sec:sys_res_limits}) usate dal processo terminato e dai vari figli. Le due funzioni sono \funcd{wait3} e \funcd{wait4}, che diventano accessibili -definendo la macro \macro{\_USE\_BSD}; i loro prototipi sono: +definendo la macro \macro{\_USE\_BSD}, i loro prototipi sono: \begin{funcproto}{ \fhead{sys/types.h} \fhead{sys/times.h} \fhead{sys/resource.h} \fhead{sys/wait.h} -\fdecl{int wait4(pid\_t pid, int *status, int options, struct rusage *rusage))} +\fdecl{int wait3(int *status, int options, struct rusage *rusage)} +\fdecl{int wait4(pid\_t pid, int *status, int options, struct rusage *rusage)} \fdesc{Attende il cambiamento di stato di un processo figlio, riportando l'uso - delle risorsr.} + delle risorse.} } {La funzione ha gli stessi valori di ritorno e codici di errore di \func{waitpid}. } \end{funcproto} +La funzione \func{wait4} è identica \func{waitpid} sia nel comportamento che +per i valori dei primi tre argomenti, ma in più restituisce nell'argomento +aggiuntivo \param{rusage} un sommario delle risorse usate dal processo. Questo +argomento è una struttura di tipo \struct{rusage} definita in +\file{sys/resource.h}, che viene utilizzata anche dalla funzione +\func{getrusage} per ottenere le risorse di sistema usate da un processo. La +sua definizione è riportata in fig.~\ref{fig:sys_rusage_struct} e ne +tratteremo in dettaglio il significato sez.~\ref{sec:sys_resource_use}. La +funzione \func{wait3} è semplicemente un caso particolare di (e con Linux +viene realizzata con la stessa \textit{system call}), ed è equivalente a +chiamare \code{wait4(-1, \&status, opt, rusage)}, per questo motivo è ormai +deprecata in favore di \func{wait4}. -\begin{functions} - \headdecl{sys/times.h} \headdecl{sys/types.h} \headdecl{sys/wait.h} - \headdecl{sys/resource.h} - - \funcdecl{pid\_t wait4(pid\_t pid, int *status, int options, struct rusage - *rusage)} - È identica a \func{waitpid} sia per comportamento che per i valori degli - argomenti, ma restituisce in \param{rusage} un sommario delle risorse usate - dal processo. - - \funcdecl{pid\_t wait3(int *status, int options, struct rusage *rusage)} - Prima versione, equivalente a \code{wait4(-1, \&status, opt, rusage)} è - ormai deprecata in favore di \func{wait4}. -\end{functions} -\noindent -la struttura \struct{rusage} è definita in \file{sys/resource.h}, e viene -utilizzata anche dalla funzione \func{getrusage} (vedi -sez.~\ref{sec:sys_resource_use}) per ottenere le risorse di sistema usate da un -processo; la sua definizione è riportata in fig.~\ref{fig:sys_rusage_struct}. - - -\subsection{La funzione \func{exec} e le funzioni di esecuzione dei programmi} + + +\subsection{La famiglia delle funzioni \func{exec} per l'esecuzione dei + programmi} \label{sec:proc_exec} Abbiamo già detto che una delle modalità principali con cui si utilizzano i processi in Unix è quella di usarli per lanciare nuovi programmi: questo viene fatto attraverso una delle funzioni della famiglia \func{exec}. Quando un processo chiama una di queste funzioni esso viene completamente sostituito dal -nuovo programma; il \acr{pid} del processo non cambia, dato che non viene +nuovo programma, il \acr{pid} del processo non cambia, dato che non viene creato un nuovo processo, la funzione semplicemente rimpiazza lo -\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. +\itindex{stack} \textit{stack}, i \index{segmento!dati} dati ed il +\index{segmento!testo} testo del processo corrente con un nuovo programma +letto da disco, eseguendo il \itindex{link-loader} \textit{link-loader} con +gli effetti illustrati in sez.~\ref{sec:proc_main}. 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}), sono tutte un front-end a -\funcd{execve}. Il prototipo di quest'ultima è: -\begin{prototype}{unistd.h} -{int execve(const char *filename, char *const argv[], char *const envp[])} - Esegue il programma contenuto nel file \param{filename}. - - \bodydesc{La funzione ritorna solo in caso di errore, restituendo -1; nel - qual caso \var{errno} può assumere i valori: - \begin{errlist} - \item[\errcode{EACCES}] il file non è eseguibile, oppure il filesystem è - montato in \cmd{noexec}, oppure non è un file regolare o un interprete. +(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 +prototipo è: + +\begin{funcproto}{ +\fhead{unistd.h} +\fdecl{int execve(const char *filename, char *const argv[], char *const envp[])} +\fdesc{Esegue un programma.} +} +{La funzione ritorna solo in caso di errore, restituendo $-1$, nel qual + caso \var{errno} assumerà uno dei valori: +\begin{errlist} + \item[\errcode{EACCES}] il file o l'interprete non file ordinari, o non sono + eseguibili, o il file è su un filesystem montato con l'opzione + \cmd{noexec}, o manca il permesso di attraversamento di una delle + directory del pathname. \item[\errcode{EPERM}] il file ha i bit \itindex{suid~bit} \acr{suid} o - \itindex{sgid~bit} \acr{sgid}, l'utente non è root, il processo viene - tracciato, o il filesystem è montato con l'opzione \cmd{nosuid}. + \itindex{sgid~bit} \acr{sgid} e l'utente non è root, ed il processo viene + tracciato, oppure il filesystem è montato con l'opzione \cmd{nosuid}. \item[\errcode{ENOEXEC}] il file è in un formato non eseguibile o non riconosciuto come tale, o compilato per un'altra architettura. \item[\errcode{ENOENT}] il file o una delle librerie dinamiche o l'interprete @@ -1395,59 +1402,53 @@ famiglia di funzioni) che possono essere usate per questo compito, in realtà riconoscibile. \item[\errcode{E2BIG}] la lista degli argomenti è troppo grande. \end{errlist} - ed inoltre anche \errval{EFAULT}, \errval{ENOMEM}, \errval{EIO}, - \errval{ENAMETOOLONG}, \errval{ELOOP}, \errval{ENOTDIR}, \errval{ENFILE}, - \errval{EMFILE}.} -\end{prototype} - -La funzione \func{exec} esegue il file o lo script indicato da -\param{filename}, passandogli la lista di argomenti indicata da \param{argv} -e come ambiente la lista di stringhe indicata da \param{envp}; entrambe le -liste devono essere terminate da un puntatore nullo. I vettori degli -argomenti e dell'ambiente possono essere acceduti dal nuovo programma -quando la sua funzione \func{main} è dichiarata nella forma + ed inoltre \errval{EFAULT}, \errval{ENOMEM}, + \errval{EIO}, \errval{ENAMETOOLONG}, \errval{ELOOP}, \errval{ENOTDIR}, + \errval{EISDIR}, \errval{ENFILE}, \errval{EMFILE} nel loro significato + generico. +} +\end{funcproto} + +La funzione \func{execve} esegue il programma o lo script indicato dal +pathname \param{filename}, passandogli la lista di argomenti indicata +da \param{argv} e come ambiente la lista di stringhe indicata +da \param{envp}. Entrambe le liste devono essere terminate da un puntatore +nullo. I vettori degli argomenti e dell'ambiente possono essere acceduti dal +nuovo programma quando la sua funzione \func{main} è dichiarata nella forma \code{main(int argc, char *argv[], char *envp[])}. -Le altre funzioni della famiglia servono per fornire all'utente una serie di -possibili diverse interfacce per la creazione di un nuovo processo. I loro -prototipi sono: -\begin{functions} -\headdecl{unistd.h} -\funcdecl{int execl(const char *path, const char *arg, ...)} -\funcdecl{int execv(const char *path, char *const argv[])} -\funcdecl{int execle(const char *path, const char *arg, ..., char -* const envp[])} -\funcdecl{int execlp(const char *file, const char *arg, ...)} -\funcdecl{int execvp(const char *file, char *const argv[])} - -Sostituiscono l'immagine corrente del processo con quella indicata nel primo -argomento. Gli argomenti successivi consentono di specificare gli argomenti a -linea di comando e l'ambiente ricevuti dal nuovo processo. - -\bodydesc{Queste funzioni ritornano solo in caso di errore, restituendo -1; - nel qual caso \var{errno} assumerà i valori visti in precedenza per - \func{execve}.} -\end{functions} - -Per capire meglio le differenze fra le funzioni della famiglia si può fare -riferimento allo specchietto riportato in tab.~\ref{tab:proc_exec_scheme}. La -prima differenza riguarda le modalità di passaggio dei valori che poi andranno -a costituire gli argomenti a linea di comando (cioè i valori di -\param{argv} e \param{argc} visti dalla funzione \func{main} del programma -chiamato). - -Queste modalità sono due e sono riassunte dagli mnemonici \code{v} e \code{l} -che stanno rispettivamente per \textit{vector} e \textit{list}. Nel primo caso -gli argomenti sono passati tramite il vettore di puntatori \var{argv[]} a -stringhe terminate con zero che costituiranno gli argomenti a riga di comando, -questo vettore \emph{deve} essere terminato da un puntatore nullo. - -Nel secondo caso le stringhe degli argomenti sono passate alla funzione come -lista di puntatori, nella forma: -\includecodesnip{listati/char_list.c} -che deve essere terminata da un puntatore nullo. In entrambi i casi vale la -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. +In caso di successo la funzione non ritorna, in quanto al posto del programma +chiamante viene eseguito il nuovo programma indicato da \param{filename}. Se +il processo corrente è tracciato con \func{ptrace} (vedi +sez.~\ref{sec:process_ptrace}) in caso di successo viene emesso il segnale +\signal{SIGTRAP}. + +Le altre funzioni della famiglia (\funcd{execl}, \funcd{execv}, +\funcd{execle}, \funcd{execlp}, \funcd{execvp}) servono per fornire all'utente +una serie di possibili diverse interfacce nelle modalità di passaggio degli +argomenti all'esecuzione del nuovo programma. I loro prototipi sono: + +\begin{funcproto}{ +\fhead{unistd.h} +\fdecl{int execl(const char *path, const char *arg, ...)} +\fdecl{int execv(const char *path, char *const argv[])} +\fdecl{int execle(const char *path, const char *arg, ..., char * const envp[])} +\fdecl{int execlp(const char *file, const char *arg, ...)} +\fdecl{int execvp(const char *file, char *const argv[])} +\fdesc{Eseguono un programma.} +} +{Le funzioni ritorna solo in caso di errore, restituendo $-1$, i codici di + errore sono gli stessi di \func{execve}. +} +\end{funcproto} + +Tutte le funzioni mettono in esecuzione nel processo corrente il programma +indicati nel primo argomento. Gli argomenti successivi consentono di +specificare gli argomenti e l'ambiente che saranno ricevuti dal nuovo +processo. Per capire meglio le differenze fra le funzioni della famiglia si può +fare riferimento allo specchietto riportato in +tab.~\ref{tab:proc_exec_scheme}. La relazione fra le funzioni è invece +illustrata in fig.~\ref{fig:proc_exec_relat}. \begin{table}[!htb] \footnotesize @@ -1476,9 +1477,33 @@ per indicare il nome del file che contiene il programma che verrà eseguito. \label{tab:proc_exec_scheme} \end{table} +La prima differenza fra le funzioni riguarda le modalità di passaggio dei +valori che poi andranno a costituire gli argomenti a linea di comando (cioè i +valori di \param{argv} e \param{argc} visti dalla funzione \func{main} del +programma chiamato). Queste modalità sono due e sono riassunte dagli mnemonici +``\texttt{v}'' e ``\texttt{l}'' che stanno rispettivamente per \textit{vector} +e \textit{list}. + +Nel primo caso gli argomenti sono passati tramite il vettore di puntatori +\var{argv[]} a stringhe terminate con zero che costituiranno gli argomenti a +riga di comando, questo vettore \emph{deve} essere terminato da un puntatore +nullo. Nel secondo caso le stringhe degli argomenti sono passate alla funzione +come lista di puntatori, nella forma: +\includecodesnip{listati/char_list.c} +che deve essere terminata da un puntatore nullo. In entrambi i casi vale la +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=12cm]{img/exec_rel} + \caption{La interrelazione fra le sei funzioni della famiglia \func{exec}.} + \label{fig:proc_exec_relat} +\end{figure} + La seconda differenza fra le funzioni riguarda le modalità con cui si -specifica il programma che si vuole eseguire. Con lo mnemonico \code{p} si -indicano le due funzioni che replicano il comportamento della shell nello +specifica il programma che si vuole eseguire. Con lo mnemonico ``\texttt{p}'' +si indicano le due funzioni che replicano il comportamento della shell nello specificare il comando da eseguire; quando l'argomento \param{file} non contiene una ``\texttt{/}'' esso viene considerato come un nome di programma, e viene eseguita automaticamente una ricerca fra i file presenti nella lista @@ -1488,43 +1513,39 @@ relativo a permessi di accesso insufficienti (cioè l'esecuzione della sottostante \func{execve} ritorna un \errcode{EACCES}), la ricerca viene proseguita nelle eventuali ulteriori directory indicate in \var{PATH}; solo se non viene trovato nessun altro file viene finalmente restituito -\errcode{EACCES}. - -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. - -\begin{figure}[!htb] - \centering \includegraphics[width=12cm]{img/exec_rel} - \caption{La interrelazione fra le sei funzioni della famiglia \func{exec}.} - \label{fig:proc_exec_relat} -\end{figure} +\errcode{EACCES}. 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. La terza differenza è come viene passata la lista delle variabili di ambiente. -Con lo mnemonico \texttt{e} vengono indicate quelle funzioni che necessitano -di un vettore di parametri \var{envp[]} analogo a quello usato per gli -argomenti a riga di comando (terminato quindi da un \val{NULL}), le altre +Con lo mnemonico ``\texttt{e}'' vengono indicate quelle funzioni che +necessitano di un vettore di parametri \var{envp[]} analogo a quello usato per +gli argomenti a riga di comando (terminato quindi da un \val{NULL}), le altre usano il valore della variabile \var{environ} (vedi sez.~\ref{sec:proc_environ}) del processo di partenza per costruire l'ambiente. -Oltre a mantenere lo stesso \acr{pid}, il nuovo programma fatto partire da -\func{exec} mantiene la gran parte delle proprietà del processo chiamante; una -lista delle più significative è la seguente: +Oltre a mantenere lo stesso \acr{pid}, il nuovo programma fatto partire da una +delle funzioni della famiglia \func{exec} mantiene la gran parte delle +proprietà del processo chiamante; una lista delle più significative è la +seguente: \begin{itemize*} \item il \textit{process id} (\acr{pid}) ed il \textit{parent process id} (\acr{ppid}); \item l'\textsl{user-ID reale}, il \textit{group-ID reale} ed i \textsl{group-ID supplementari} (vedi sez.~\ref{sec:proc_access_id}); -\item il \textit{session ID} (\acr{sid}) ed il \itindex{process~group} - \textit{process group ID} (\acr{pgid}), vedi sez.~\ref{sec:sess_proc_group}; -\item il terminale di controllo (vedi sez.~\ref{sec:sess_ctrl_term}); -\item il tempo restante ad un allarme (vedi sez.~\ref{sec:sig_alarm_abort}); \item la directory radice e la directory di lavoro corrente (vedi sez.~\ref{sec:file_work_dir}); \item la maschera di creazione dei file \itindex{umask} (\textit{umask}, vedi sez.~\ref{sec:file_perm_management}) ed i \textit{lock} sui file (vedi sez.~\ref{sec:file_locking}); +\item il valori di \textit{nice}, le priorità real-time e le affinità di + processore (vedi sez.~\ref{sec:proc_sched_stand}; + sez.~\ref{sec:proc_real_time} e sez.~\ref{sec:proc_sched_multiprocess}); +\item il \textit{session ID} (\acr{sid}) ed il \itindex{process~group} + \textit{process group ID} (\acr{pgid}), vedi sez.~\ref{sec:sess_proc_group}; +\item il terminale di controllo (vedi sez.~\ref{sec:sess_ctrl_term}); +\item il tempo restante ad un allarme (vedi sez.~\ref{sec:sig_alarm_abort}); \item i limiti sulle risorse (vedi sez.~\ref{sec:sys_resource_limit}); \item i valori delle variabili \var{tms\_utime}, \var{tms\_stime}; \var{tms\_cutime}, \var{tms\_ustime} (vedi sez.~\ref{sec:sys_cpu_times}); @@ -1537,8 +1558,8 @@ lista delle più significative è la seguente: Una serie di proprietà del processo originale, che non avrebbe senso mantenere in un programma che esegue un codice completamente diverso in uno spazio di indirizzi totalmente indipendente e ricreato da zero, vengono perse con -l'esecuzione di \func{exec}; lo standard POSIX.1-2001 prevede che le seguenti -proprietà non vengano preservate: +l'esecuzione di una \func{exec}. Lo standard POSIX.1-2001 prevede che le +seguenti proprietà non vengano preservate: \begin{itemize*} \item l'insieme dei segnali pendenti (vedi sez.~\ref{sec:sig_gen_beha}), che viene cancellato; @@ -1549,30 +1570,29 @@ proprietà non vengano preservate: \item le mappature dei file in memoria (vedi sez.~\ref{sec:file_memory_map}); \item i segmenti di memoria condivisa SysV (vedi sez.~\ref{sec:ipc_sysv_shm}) e POSIX (vedi sez.~\ref{sec:ipc_posix_shm}); -\item i blocchi sulla memoria (vedi sez.~\ref{sec:proc_mem_lock}); +\item i \textit{memory lock} (vedi sez.~\ref{sec:proc_mem_lock}); \item le funzioni registrate all'uscita (vedi sez.~\ref{sec:proc_atexit}); \item i semafori e le code di messaggi POSIX (vedi sez.~\ref{sec:ipc_posix_sem} e sez.~\ref{sec:ipc_posix_mq}); \item i timer POSIX (vedi sez.~\ref{sec:sig_timer_adv}). \end{itemize*} -I segnali che sono stati impostati per essere ignorati nel processo chiamante -mantengono la stessa impostazione pure nel nuovo programma, ma tutti gli altri -segnali, ed in particolare quelli per i quali è stato installato un gestore -vengono impostati alla loro azione predefinita (vedi +Inoltre i segnali che sono stati impostati per essere ignorati nel processo +chiamante mantengono la stessa impostazione pure nel nuovo programma, ma tutti +gli altri segnali, ed in particolare quelli per i quali è stato installato un +gestore vengono impostati alla loro azione predefinita (vedi sez.~\ref{sec:sig_gen_beha}). Un caso speciale è il segnale \signal{SIGCHLD} che, quando impostato a \const{SIG\_IGN}, potrebbe anche essere reimpostato a -\const{SIG\_DFL}, anche se questo con Linux non avviene.\footnote{lo standard - POSIX.1-2001 prevede che questo comportamento sia deciso dalla singola - implementazione, quella di Linux è di non modificare l'impostazione - precedente.} +\const{SIG\_DFL}. Lo standard POSIX.1-2001 prevede che questo comportamento +sia deciso dalla singola implementazione, quella di Linux è di non modificare +l'impostazione precedente. -Oltre alle precedenti che sono completamente generali e disponibili anche su -altri sistemi unix-like, esistono altre proprietà dei processi, attinenti +Oltre alle precedenti, che sono completamente generali e disponibili anche su +altri sistemi unix-like, esistono altre proprietà dei processi, attinenti alle caratteristiche specifiche di Linux, che non vengono preservate nell'esecuzione della funzione \func{exec}, queste sono: \begin{itemize*} -\item le operazione di I/O asincrono (vedi sez.~\ref{sec:file_asyncronous_io}) +\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 illustrato in sez.~\ref{sec:proc_capabilities}; @@ -1594,13 +1614,13 @@ nell'esecuzione della funzione \func{exec}, queste sono: 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 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 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 +\textit{close-on-exec} (vedi sez.~\ref{sec:file_fcntl}) 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. @@ -1612,7 +1632,7 @@ sez.~\ref{sec:proc_access_id} per la definizione di questi identificatori) come l'\textsl{user-ID reale} ed il \textsl{group-ID reale} restano sempre gli stessi, mentre l'\textsl{user-ID salvato} ed il \textsl{group-ID salvato} vengono impostati rispettivamente all'\textsl{user-ID effettivo} ed il -\textsl{group-ID effettivo}, questi ultimi normalmente non vengono modificati, +\textsl{group-ID effettivo}. Questi ultimi normalmente non vengono modificati, a meno che il file di cui viene chiesta l'esecuzione non 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 @@ -1630,27 +1650,30 @@ stesso, in genere questo è \sysfile{/lib/ld-linux.so.1} per programmi collegati con le \acr{libc5}, e \sysfile{/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 -forma \cmd{\#!/path/to/interpreter [argomenti]} dove l'interprete indicato -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'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 - \href{http://www.in-ulm.de/~mascheck/various/shebang/} - {\textsf{http://www.in-ulm.de/\tild mascheck/various/shebang/}}.} +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 +nella forma: +\begin{Example} +\#!/path/to/interpreter [argomenti] +\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/}.} Con la famiglia delle \func{exec} si chiude il novero delle funzioni su cui è -basata la gestione dei processi in Unix: con \func{fork} si crea un nuovo -processo, con \func{exec} si lancia un nuovo programma, con \func{exit} e -\func{wait} si effettua e verifica la conclusione dei processi. Tutte le -altre funzioni sono ausiliarie e servono per la lettura e l'impostazione dei -vari parametri connessi ai processi. +basata la gestione tradizionale dei processi in Unix: con \func{fork} si crea +un nuovo processo, con \func{exec} si lancia un nuovo programma, con +\func{exit} e \func{wait} si effettua e verifica la conclusione dei +processi. Tutte le altre funzioni sono ausiliarie e servono per la lettura e +l'impostazione dei vari parametri connessi ai processi. @@ -1678,20 +1701,22 @@ Come accennato in sez.~\ref{sec:intro_multiuser} il modello base\footnote{in 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.} 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. + 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. 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 +identificatori univoci, lo \textsl{user-ID} (abbreviato in \acr{uid}) ed il +\textsl{group-ID} (abbreviato in \acr{gid}). Questi servono al kernel per identificare uno specifico utente o un gruppo di utenti, per poi poter controllare che essi siano autorizzati a compiere le operazioni richieste. Ad -esempio in sez.~\ref{sec:file_access_control} vedremo come ad ogni file vengano -associati un utente ed un gruppo (i suoi \textsl{proprietari}, indicati -appunto tramite un \acr{uid} ed un \acr{gid}) che vengono controllati dal -kernel nella gestione dei permessi di accesso. +esempio in sez.~\ref{sec:file_access_control} vedremo come ad ogni file +vengano associati un utente ed un gruppo (i suoi \textsl{proprietari}, +indicati appunto tramite un \acr{uid} ed un \acr{gid}) che vengono controllati +dal kernel nella gestione dei permessi di accesso. Dato che tutte le operazioni del sistema vengono compiute dai processi, è evidente che per poter implementare un controllo sulle operazioni occorre @@ -1701,13 +1726,13 @@ anche a ciascun processo dovrà essere associato un utente e un gruppo. Un semplice controllo di una corrispondenza fra identificativi non garantisce però sufficiente flessibilità per tutti quei casi in cui è necessario poter disporre di privilegi diversi, o dover impersonare un altro utente per un -limitato insieme di operazioni. Per questo motivo in generale tutti gli Unix -prevedono che i processi abbiano almeno due gruppi di identificatori, chiamati -rispettivamente \textit{real} ed \textit{effective} (cioè \textsl{reali} ed -\textsl{effettivi}). Nel caso di Linux si aggiungono poi altri due gruppi, il -\textit{saved} (\textsl{salvati}) ed il \textit{filesystem} (\textsl{di - filesystem}), secondo la situazione illustrata in -tab.~\ref{tab:proc_uid_gid}. +limitato insieme di operazioni. Per questo motivo in generale tutti i sistemi +unix-like prevedono che i processi abbiano almeno due gruppi di +identificatori, chiamati rispettivamente \textit{real} ed \textit{effective} +(cioè \textsl{reali} ed \textsl{effettivi}). Nel caso di Linux si aggiungono +poi altri due gruppi, il \textit{saved} (\textsl{salvati}) ed il +\textit{filesystem} (\textsl{di filesystem}), secondo la situazione illustrata +in tab.~\ref{tab:proc_uid_gid}. \begin{table}[htb] \footnotesize @@ -1747,8 +1772,8 @@ tab.~\ref{tab:proc_uid_gid}. \label{tab:proc_uid_gid} \end{table} -Al primo gruppo appartengono l'\textsl{user-ID reale} ed il \textsl{group-ID - reale}: questi vengono impostati al login ai valori corrispondenti +Al primo gruppo appartengono l'\acr{uid} \textsl{reale} ed il \acr{gid} +\textsl{reale}: questi vengono impostati al login ai valori corrispondenti all'utente con cui si accede al sistema (e relativo gruppo principale). Servono per l'identificazione dell'utente e normalmente non vengono mai cambiati. In realtà vedremo (in sez.~\ref{sec:proc_setuid}) che è possibile @@ -1758,11 +1783,11 @@ completata la procedura di autenticazione, lancia una shell per la quale imposta questi identificatori ai valori corrispondenti all'utente che entra nel sistema. -Al secondo gruppo appartengono lo \textsl{user-ID effettivo} ed il -\textsl{group-ID effettivo} (a cui si aggiungono gli eventuali \textsl{group-ID - supplementari} dei gruppi dei quali l'utente fa parte). Questi sono invece -gli identificatori usati nelle verifiche dei permessi del processo e per il -controllo di accesso ai file (argomento affrontato in dettaglio in +Al secondo gruppo appartengono l'\acr{uid} \textsl{effettivo} e il \acr{gid} +\textsl{effettivo}, a cui si aggiungono gli eventuali \acr{gid} +\textsl{supplementari} dei gruppi dei quali l'utente fa parte. Questi sono +invece gli identificatori usati nelle verifiche dei permessi del processo e +per il controllo di accesso ai file (argomento affrontato in dettaglio in sez.~\ref{sec:file_perm_overview}). Questi identificatori normalmente sono identici ai corrispondenti del gruppo @@ -1772,32 +1797,32 @@ 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_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). +cui ci sia questa necessità, di dare a qualunque utente i privilegi o i +permessi di un altro, compreso l'amministratore. Come nel caso del \acr{pid} e del \acr{ppid}, anche tutti questi -identificatori possono essere letti attraverso le rispettive funzioni: -\funcd{getuid}, \funcd{geteuid}, \funcd{getgid} e \funcd{getegid}, i loro -prototipi sono: -\begin{functions} - \headdecl{unistd.h} - \headdecl{sys/types.h} - \funcdecl{uid\_t getuid(void)} Restituisce l'\textsl{user-ID reale} del - processo corrente. +identificatori possono essere ottenuti da un programma attraverso altrettante +funzioni di lettura, queste sono \funcd{getuid}, \funcd{geteuid}, +\funcd{getgid} e \funcd{getegid}, ed i loro prototipi sono: - \funcdecl{uid\_t geteuid(void)} Restituisce l'\textsl{user-ID effettivo} del - processo corrente. - - \funcdecl{gid\_t getgid(void)} Restituisce il \textsl{group-ID reale} del - processo corrente. - - \funcdecl{gid\_t getegid(void)} Restituisce il \textsl{group-ID effettivo} - del processo corrente. - - \bodydesc{Queste funzioni non riportano condizioni di errore.} -\end{functions} +\begin{funcproto}{ +\fhead{unistd.h} +\fhead{sys/types.h} +\fdecl{uid\_t getuid(void)} +\fdesc{Legge l'\textsl{user-ID reale} del processo corrente.} +\fdecl{uid\_t geteuid(void)} +\fdesc{Legge l'\textsl{user-ID effettivo} del processo corrente.} +\fdecl{gid\_t getgid(void)} +\fdesc{Legge il \textsl{group-ID reale} del processo corrente.} +\fdecl{gid\_t getegid(void)} +\fdesc{Legge il \textsl{group-ID effettivo} del processo corrente.} +} +{Le funzioni ritornano i rispettivi identificativi del processo corrente, e + non sono previste condizioni di errore.} +\end{funcproto} -In generale l'uso di privilegi superiori deve essere limitato il più +In generale l'uso di privilegi superiori, ottenibile con un \acr{uid} +\textsl{effettivo} diverso da quello reale, deve essere limitato il più possibile, per evitare abusi e problemi di sicurezza, per questo occorre anche un meccanismo che consenta ad un programma di rilasciare gli eventuali maggiori privilegi necessari, una volta che si siano effettuate le operazioni @@ -1811,18 +1836,19 @@ SVr4, e previsto dallo standard POSIX quando è definita la costante del programma su altri Unix è buona norma controllare sempre la disponibilità di queste funzioni controllando se questa costante è definita.} il secondo gruppo è specifico di Linux e viene usato per -migliorare la sicurezza con NFS. - -L'\textsl{user-ID salvato} ed il \textsl{group-ID salvato} sono copie -dell'\textsl{user-ID effettivo} e del \textsl{group-ID effettivo} del processo -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 -consentono di tenere traccia di quale fossero utente e gruppo effettivi +migliorare la sicurezza con NFS (il \textit{Network File System}, protocollo +che consente di accedere ai file via rete). + +L'\acr{uid} \textsl{salvato} ed il \acr{gid} \textsl{salvato} sono copie +dell'\acr{uid} \textsl{effettivo} e del \acr{gid} \textsl{effettivo} del +processo padre, e vengono impostati dalla funzione \func{exec} all'avvio del +processo, come copie dell'\acr{uid} \textsl{effettivo} e del \acr{gid} +\textsl{effettivo} dopo che questi sono stati impostati tenendo conto di +eventuali \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. -L'\textsl{user-ID di filesystem} e il \textsl{group-ID di filesystem} sono +L'\acr{uid} \textsl{di filesystem} e il \acr{gid} \textsl{di filesystem} sono un'estensione introdotta in Linux per rendere più sicuro l'uso di NFS (torneremo sull'argomento in sez.~\ref{sec:proc_setuid}). Essi sono una replica dei corrispondenti identificatori del gruppo \textit{effective}, ai @@ -1842,51 +1868,50 @@ utente e gruppo di appartenenza) ad un processo sono rispettivamente sez.~\ref{sec:proc_access_id} in Linux esse seguono la semantica POSIX che prevede l'esistenza dell'\textit{user-ID salvato} e del \textit{group-ID salvato}; i loro prototipi sono: -\begin{functions} -\headdecl{unistd.h} -\headdecl{sys/types.h} -\funcdecl{int setuid(uid\_t uid)} Imposta l'\textsl{user-ID} del processo -corrente. - -\funcdecl{int setgid(gid\_t gid)} Imposta il \textsl{group-ID} del processo -corrente. - -\bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 in caso - di fallimento: l'unico errore possibile è \errval{EPERM}.} -\end{functions} +\begin{funcproto}{ +\fhead{unistd.h} +\fhead{sys/types.h} +\fdecl{int setuid(uid\_t uid)} +\fdesc{Imposta l'\acr{uid} del processo corrente.} +\fdecl{int setgid(gid\_t gid)} +\fdesc{Imposta il \acr{gid} del processo corrente.} +} +{Le funzioni ritornano $0$ in caso di successo e $-1$ per un errore, nel qual +caso \var{errno} può assumere solo il valore \errval{EPERM}. +} +\end{funcproto} Il funzionamento di queste due funzioni è analogo, per cui considereremo solo -la prima; la seconda si comporta esattamente allo stesso modo facendo -riferimento al \textsl{group-ID} invece che all'\textsl{user-ID}. Gli -eventuali \textsl{group-ID supplementari} non vengono modificati. +la prima, la seconda si comporta esattamente allo stesso modo facendo +riferimento al \acr{gid} invece che all'\acr{uid}. Gli eventuali \acr{gid} +supplementari non vengono modificati. L'effetto della chiamata è diverso a seconda dei privilegi del processo; se -l'\textsl{user-ID effettivo} è zero (cioè è quello dell'amministratore di -sistema) allora tutti gli identificatori (\textit{real}, \textit{effective} e +l'\acr{uid} effettivo è zero (cioè è quello dell'amministratore di sistema) +allora tutti gli identificatori (\textit{real}, \textit{effective} e \textit{saved}) vengono impostati al valore specificato da \param{uid}, -altrimenti viene impostato solo l'\textsl{user-ID effettivo}, e soltanto se il -valore specificato corrisponde o all'\textsl{user-ID reale} o -all'\textsl{user-ID salvato}. Negli altri casi viene segnalato un errore (con -\errcode{EPERM}). +altrimenti viene impostato solo l'\acr{uid} effettivo, e soltanto se il valore +specificato corrisponde o all'\acr{uid} reale o all'\acr{uid} salvato. Negli +altri casi viene segnalato un errore con \errcode{EPERM}. 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_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. +\itindex{sgid~bit} \acr{sgid} impostati (vedi +sez.~\ref{sec:file_special_perm}) di riportare l'\acr{uid} effettivo a quello +dell'utente che ha lanciato il programma, effettuare il lavoro che non +necessita di privilegi aggiuntivi, ed eventualmente tornare indietro. Come esempio per chiarire l'uso di queste funzioni prendiamo quello con cui -viene gestito l'accesso al file \sysfile{/var/log/utmp}. In questo file viene +viene gestito l'accesso al file \sysfile{/var/run/utmp}. In questo file viene registrato chi sta usando il sistema al momento corrente; chiaramente non può essere lasciato aperto in scrittura a qualunque utente, che potrebbe falsificare la registrazione. Per questo motivo questo file (e l'analogo \sysfile{/var/log/wtmp} su cui vengono registrati login e logout) appartengono -ad un gruppo dedicato (\acr{utmp}) ed i programmi che devono accedervi (ad -esempio tutti i programmi di terminale in X, o il programma \cmd{screen} che -crea terminali multipli su una console) appartengono a questo gruppo ed hanno -il bit \acr{sgid} impostato. +ad un gruppo dedicato (in genere \acr{utmp}) ed i programmi che devono +accedervi (ad esempio tutti i programmi di terminale in X, o il programma +\cmd{screen} che crea terminali multipli su una console) appartengono a questo +gruppo ed hanno il bit \acr{sgid} impostato. Quando uno di questi programmi (ad esempio \cmd{xterm}) viene lanciato, la situazione degli identificatori è la seguente: @@ -1897,7 +1922,7 @@ situazione degli identificatori è la seguente: \textsl{group-ID salvato} &=& \textrm{\acr{utmp}} \end{eqnarray*} in questo modo, dato che il \textsl{group-ID effettivo} è quello giusto, il -programma può accedere a \sysfile{/var/log/utmp} in scrittura ed aggiornarlo. +programma può accedere a \sysfile{/var/run/utmp} in scrittura ed aggiornarlo. A questo punto il programma può eseguire una \code{setgid(getgid())} per impostare il \textsl{group-ID effettivo} a quello dell'utente (e dato che il \textsl{group-ID reale} corrisponde la funzione avrà successo), in questo modo @@ -1911,7 +1936,7 @@ in tal caso infatti la situazione degli identificatori sarebbe: \end{eqnarray*} e ogni processo lanciato dal terminale avrebbe comunque \acr{gid} come \textsl{group-ID effettivo}. All'uscita dal terminale, per poter di nuovo -aggiornare lo stato di \sysfile{/var/log/utmp} il programma eseguirà una +aggiornare lo stato di \sysfile{/var/run/utmp} il programma eseguirà una \code{setgid(utmp)} (dove \var{utmp} è il valore numerico associato al gruppo \acr{utmp}, ottenuto ad esempio con una precedente \func{getegid}), dato che in questo caso il valore richiesto corrisponde al \textsl{group-ID salvato} la @@ -1922,142 +1947,144 @@ funzione avrà successo e riporterà la situazione a: \textsl{group-ID effettivo} &=& \textrm{\acr{utmp}} \\ \textsl{group-ID salvato} &=& \textrm{\acr{utmp} (invariato)} \end{eqnarray*} -consentendo l'accesso a \sysfile{/var/log/utmp}. +consentendo l'accesso a \sysfile{/var/run/utmp}. Occorre però tenere conto che tutto questo non è possibile con un processo con i privilegi di amministratore, in tal caso infatti l'esecuzione di una \func{setuid} comporta il cambiamento di tutti gli identificatori associati al processo, rendendo impossibile riguadagnare i privilegi di amministratore. Questo comportamento è corretto per l'uso che ne fa \cmd{login} una volta che -crea una nuova shell per l'utente; ma quando si vuole cambiare soltanto +crea una nuova shell per l'utente, ma quando si vuole cambiare soltanto l'\textsl{user-ID effettivo} del processo per cedere i privilegi occorre 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.} 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} - -\funcdecl{int setreuid(uid\_t ruid, uid\_t euid)} Imposta l'\textsl{user-ID - reale} e l'\textsl{user-ID effettivo} del processo corrente ai valori -specificati da \param{ruid} e \param{euid}. - -\funcdecl{int setregid(gid\_t rgid, gid\_t egid)} Imposta il \textsl{group-ID - reale} ed il \textsl{group-ID effettivo} del processo corrente ai valori -specificati da \param{rgid} e \param{egid}. - -\bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 in caso - di fallimento: l'unico errore possibile è \errval{EPERM}.} -\end{functions} - -La due funzioni sono analoghe ed il loro comportamento è identico; quanto -detto per la prima riguardo l'user-ID, si applica immediatamente alla seconda -per il group-ID. I processi non privilegiati possono impostare solo i valori -del loro user-ID effettivo o reale; valori diversi comportano il fallimento -della chiamata; l'amministratore invece può specificare un valore qualunque. -Specificando un argomento di valore -1 l'identificatore corrispondente verrà -lasciato inalterato. - -Con queste funzioni si possono scambiare fra loro gli user-ID reale e +supportando (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{funcproto}{ +\fhead{unistd.h} +\fhead{sys/types.h} +\fdecl{int setreuid(uid\_t ruid, uid\_t euid)} +\fdesc{Imposta \acr{uid} reale e \acr{uid} effettivo del processo corrente.} +\fdecl{int setregid(gid\_t rgid, gid\_t egid)} +\fdesc{Imposta \acr{gid} reale e \acr{gid} effettivo del processo corrente.} +} +{Le funzioni ritornano $0$ in caso di successo e $-1$ per un errore, nel qual +caso \var{errno} può assumere solo il valore \errval{EPERM}. +} +\end{funcproto} + +Le due funzioni sono identiche, quanto diremo per la prima riguardo gli +\acr{uid} si applica alla seconda per i \acr{gid}. La funzione +\func{setreuid} imposta rispettivamente l'\acr{uid} reale e l'\acr{uid} +effettivo del processo corrente ai valori specificati da \param{ruid} +e \param{euid}. I processi non privilegiati possono impostare solo valori che +corrispondano o al loro \acr{uid} effettivo o a quello reale o a quello +salvato, valori diversi comportano il fallimento della chiamata. +L'amministratore invece può specificare un valore qualunque. Specificando un +argomento di valore $-1$ l'identificatore corrispondente verrà lasciato +inalterato. + +Con queste funzioni si possono scambiare fra loro gli \acr{uid} reale ed effettivo, e pertanto è possibile implementare un comportamento simile a quello visto in precedenza per \func{setgid}, cedendo i privilegi con un primo -scambio, e recuperandoli, eseguito il lavoro non privilegiato, con un secondo -scambio. +scambio, e recuperandoli, una volta eseguito il lavoro non privilegiato, con +un secondo scambio. In questo caso però occorre porre molta attenzione quando si creano nuovi processi nella fase intermedia in cui si sono scambiati gli identificatori, in -questo caso infatti essi avranno un user-ID reale privilegiato, che dovrà +questo caso infatti essi avranno un \acr{uid} reale privilegiato, che dovrà essere esplicitamente eliminato prima di porre in esecuzione un nuovo -programma (occorrerà cioè eseguire un'altra chiamata dopo la \func{fork} e -prima della \func{exec} per uniformare l'user-ID reale a quello effettivo) in -caso contrario il nuovo programma potrebbe a sua volta effettuare uno scambio -e riottenere privilegi non previsti. +programma, occorrerà cioè eseguire un'altra chiamata dopo la \func{fork} e +prima della \func{exec} per uniformare l'\acr{uid} reale a quello effettivo, +perché in caso contrario il nuovo programma potrebbe a sua volta effettuare +uno scambio e riottenere dei privilegi non previsti. Lo stesso problema di propagazione dei privilegi ad eventuali processi figli -si pone per l'user-ID salvato: questa funzione deriva da un'implementazione che -non ne prevede la presenza, e quindi non è possibile usarla per correggere la -situazione come nel caso precedente. Per questo motivo in Linux tutte le volte -che si imposta un qualunque valore diverso da quello dall'user-ID reale -corrente, l'user-ID salvato viene automaticamente uniformato al valore -dell'user-ID effettivo. +si pone anche per l'\acr{uid} salvato. Ma la funzione \func{setreuid} deriva +da un'implementazione di sistema che non ne prevede la presenza, e quindi non +è possibile usarla per correggere la situazione come nel caso precedente. Per +questo motivo in Linux tutte le volte che si imposta un qualunque valore +diverso da quello dall'\acr{uid} reale corrente, l'\acr{uid} salvato viene +automaticamente uniformato al valore dell'\acr{uid} effettivo. Altre due funzioni, \funcd{seteuid} e \funcd{setegid}, sono un'estensione dello standard POSIX.1, ma sono comunque supportate dalla maggior parte degli -Unix; esse vengono usate per cambiare gli identificatori del gruppo +Unix, esse vengono usate per cambiare gli identificatori del gruppo \textit{effective} ed i loro prototipi sono: -\begin{functions} -\headdecl{unistd.h} -\headdecl{sys/types.h} - -\funcdecl{int seteuid(uid\_t uid)} Imposta l'user-ID effettivo del processo -corrente a \param{uid}. - -\funcdecl{int setegid(gid\_t gid)} Imposta il group-ID effettivo del processo -corrente a \param{gid}. - -\bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 in caso - di fallimento: l'unico errore è \errval{EPERM}.} -\end{functions} - -Come per le precedenti le due funzioni sono identiche, per cui tratteremo solo -la prima. Gli utenti normali possono impostare l'user-ID effettivo solo al -valore dell'user-ID reale o dell'user-ID salvato, l'amministratore può -specificare qualunque valore. Queste funzioni sono usate per permettere -all'amministratore di impostare solo l'user-ID effettivo, dato che l'uso -normale di \func{setuid} comporta l'impostazione di tutti gli identificatori. - +\begin{funcproto}{ +\fhead{unistd.h} +\fhead{sys/types.h} +\fdecl{int seteuid(uid\_t uid)} +\fdesc{Imposta l'\acr{uid} effettivo del processo corrente.} +\fdecl{int setegid(gid\_t gid)} +\fdesc{Imposta il \acr{gid} effettivo del processo corrente.} +} +{Le funzioni ritornano $0$ in caso di successo e $-1$ per un errore, nel qual +caso \var{errno} può assumere solo il valore \errval{EPERM}. +} +\end{funcproto} + +Ancora una volta le due funzioni sono identiche, e quanto diremo per la prima +riguardo gli \acr{uid} si applica allo stesso modo alla seconda per i +\acr{gid}. Con \func{seteuid} gli utenti normali possono impostare l'\acr{uid} +effettivo solo al valore dell'\acr{uid} reale o dell'\acr{uid} salvato, +l'amministratore può specificare qualunque valore. Queste funzioni sono usate +per permettere all'amministratore di impostare solo l'\acr{uid} effettivo, +dato che l'uso normale di \func{setuid} comporta l'impostazione di tutti gli +identificatori. + Le due funzioni \funcd{setresuid} e \funcd{setresgid} sono invece -un'estensione introdotta in Linux,\footnote{per essere precisi a partire dal - kernel 2.1.44.} e permettono un completo controllo su tutti e tre i gruppi -di identificatori (\textit{real}, \textit{effective} e \textit{saved}), i loro -prototipi sono: -\begin{functions} -\headdecl{unistd.h} -\headdecl{sys/types.h} - -\funcdecl{int setresuid(uid\_t ruid, uid\_t euid, uid\_t suid)} Imposta -l'user-ID reale, l'user-ID effettivo e l'user-ID salvato del processo corrente -ai valori specificati rispettivamente da \param{ruid}, \param{euid} e -\param{suid}. - -\funcdecl{int setresgid(gid\_t rgid, gid\_t egid, gid\_t sgid)} Imposta il -group-ID reale, il group-ID effettivo ed il group-ID salvato del processo -corrente ai valori specificati rispettivamente da \param{rgid}, \param{egid} e -\param{sgid}. - -\bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 in caso - di fallimento: l'unico errore è \errval{EPERM}.} -\end{functions} - -Le due funzioni sono identiche, quanto detto per la prima riguardo gli user-ID -si applica alla seconda per i group-ID. I processi non privilegiati possono -cambiare uno qualunque degli user-ID solo ad un valore corrispondente o -all'user-ID reale, o a quello effettivo o a quello salvato, l'amministratore -può specificare i valori che vuole; un valore di -1 per un qualunque argomento -lascia inalterato l'identificatore corrispondente. - -Per queste funzioni esistono anche due controparti che permettono di leggere -in blocco i vari identificatori: \funcd{getresuid} e \funcd{getresgid}; i loro -prototipi sono: -\begin{functions} -\headdecl{unistd.h} -\headdecl{sys/types.h} - -\funcdecl{int getresuid(uid\_t *ruid, uid\_t *euid, uid\_t *suid)} Legge -l'user-ID reale, l'user-ID effettivo e l'user-ID salvato del processo corrente. - -\funcdecl{int getresgid(gid\_t *rgid, gid\_t *egid, gid\_t *sgid)} Legge il -group-ID reale, il group-ID effettivo e il group-ID salvato del processo -corrente. +un'estensione introdotta in Linux (a partire dal kernel 2.1.44) e permettono +un completo controllo su tutti e tre i gruppi di identificatori +(\textit{real}, \textit{effective} e \textit{saved}), i loro prototipi sono: -\bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 in caso di - fallimento: l'unico errore possibile è \errval{EFAULT} se gli indirizzi delle - variabili di ritorno non sono validi.} -\end{functions} +\begin{funcproto}{ +\fhead{unistd.h} +\fhead{sys/types.h} +\fdecl{int setresuid(uid\_t ruid, uid\_t euid, uid\_t suid)} +\fdesc{Imposta l'\acr{uid} reale, effettivo e salvato del processo corrente.} +\fdecl{int setresgid(gid\_t rgid, gid\_t egid, gid\_t sgid)} +\fdesc{Imposta il \acr{gid} reale, effettivo e salvato del processo corrente.} +} +{Le funzioni ritornano $0$ in caso di successo e $-1$ per un errore, nel qual +caso \var{errno} può assumere solo il valore \errval{EPERM}. +} +\end{funcproto} + +Di nuovo le due funzioni sono identiche e quanto detto per la prima riguardo +gli \acr{uid} si applica alla seconda per i \acr{gid}. La funzione +\func{setresuid} imposta l'\acr{uid} reale, l'\acr{uid} effettivo e +l'\acr{uid} salvato del processo corrente ai valori specificati +rispettivamente dagli argomenti \param{ruid}, \param{euid} e \param{suid}. I +processi non privilegiati possono cambiare uno qualunque degli\acr{uid} solo +ad un valore corrispondente o all'\acr{uid} reale, o a quello effettivo o a +quello salvato, l'amministratore può specificare i valori che vuole. Un valore +di $-1$ per un qualunque argomento lascia inalterato l'identificatore +corrispondente. + +Per queste funzioni esistono anche due controparti, \funcd{getresuid} e +\funcd{getresgid},\footnote{le funzioni non sono standard, anche se appaiono + in altri kernel, su Linux sono presenti dal kernel 2.1.44 e con le versioni + della \acr{glibc} a partire dalla 2.3.2, definendo la macro + \macro{\_GNU\_SOURCE}.} che permettono di leggere in blocco i vari +identificatori; i loro prototipi sono: + +\begin{funcproto}{ +\fhead{unistd.h} +\fhead{sys/types.h} +\fdecl{int getresuid(uid\_t *ruid, uid\_t *euid, uid\_t *suid)} +\fdesc{Legge l'\acr{uid} reale, effettivo e salvato del processo corrente.} +\fdecl{int getresgid(gid\_t *rgid, gid\_t *egid, gid\_t *sgid)} +\fdesc{Legge il \acr{gid} reale, effettivo e salvato del processo corrente.} +} +{Le funzioni ritornano $0$ in caso di successo e $-1$ per un errore, nel qual + caso \var{errno} può assumere solo il valore \errval{EFAULT} se gli + indirizzi delle variabili di ritorno non sono validi. } +\end{funcproto} Anche queste funzioni sono un'estensione specifica di Linux, e non richiedono nessun privilegio. I valori sono restituiti negli argomenti, che vanno @@ -2066,7 +2093,6 @@ specificati come puntatori (è un altro esempio di queste funzioni sono le uniche in grado di leggere gli identificatori del gruppo \textit{saved}. - Infine le funzioni \func{setfsuid} e \func{setfsgid} servono per impostare gli identificatori del gruppo \textit{filesystem} che sono usati da Linux per il controllo dell'accesso ai file. Come già accennato in @@ -2082,32 +2108,34 @@ implementare un server NFS. Il server NFS infatti deve poter cambiare l'identificatore con cui accede ai file per assumere l'identità del singolo utente remoto, ma se questo viene -fatto cambiando l'user-ID effettivo o l'user-ID reale il server si espone alla -ricezione di eventuali segnali ostili da parte dell'utente di cui ha -temporaneamente assunto l'identità. Cambiando solo l'user-ID di filesystem si -ottengono i privilegi necessari per accedere ai file, mantenendo quelli +fatto cambiando l'\acr{uid} effettivo o l'\acr{uid} reale il server si espone +alla ricezione di eventuali segnali ostili da parte dell'utente di cui ha +temporaneamente assunto l'identità. Cambiando solo l'\acr{uid} di filesystem +si ottengono i privilegi necessari per accedere ai file, mantenendo quelli originari per quanto riguarda tutti gli altri controlli di accesso, così che l'utente non possa inviare segnali al server NFS. Le due funzioni usate per cambiare questi identificatori sono \funcd{setfsuid} -e \funcd{setfsgid}, ovviamente sono specifiche di Linux e non devono essere +e \funcd{setfsgid}, ed ovviamente sono specifiche di Linux e non devono essere usate se si intendono scrivere programmi portabili; i loro prototipi sono: -\begin{functions} -\headdecl{sys/fsuid.h} -\funcdecl{int setfsuid(uid\_t fsuid)} Imposta l'user-ID di filesystem del -processo corrente a \param{fsuid}. - -\funcdecl{int setfsgid(gid\_t fsgid)} Imposta il group-ID di filesystem del -processo corrente a \param{fsgid}. +\begin{funcproto}{ +\fhead{sys/fsuid.h} +\fdecl{int setfsuid(uid\_t fsuid)} +\fdesc{Imposta l'\acr{uid} di filesystem del processo corrente.} +\fdecl{int setfsgid(gid\_t fsgid)} +\fdesc{Legge il \acr{gid} di filesystem del processo corrente.} +} +{Le funzioni restituiscono il nuovo valore dell'identificativo in caso di + successo e quello corrente per un errore, in questo caso non viene però + impostato nessun codice di errore in \var{errno}.} +\end{funcproto} -\bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 in caso - di fallimento: l'unico errore possibile è \errval{EPERM}.} -\end{functions} -\noindent queste funzioni hanno successo solo se il processo chiamante ha i -privilegi di amministratore o, per gli altri utenti, se il valore specificato -coincide con uno dei di quelli del gruppo \textit{real}, \textit{effective} o -\textit{saved}. +Le due funzioni sono analoghe ed usano il valore passato come argomento per +effettuare l'impostazione dell'identificativo. Le funzioni hanno successo +solo se il processo chiamante ha i privilegi di amministratore o, per gli +altri utenti, se il valore specificato coincide con uno dei di quelli del +gruppo \textit{real}, \textit{effective} o \textit{saved}. \subsection{Le funzioni per la gestione dei gruppi associati a un processo} @@ -2124,96 +2152,107 @@ ereditati dal processo padre e possono essere cambiati con queste funzioni. La funzione che permette di leggere i gruppi supplementari associati ad un processo è \funcd{getgroups}; questa funzione è definita nello standard POSIX.1, ed il suo prototipo è: -\begin{functions} - \headdecl{sys/types.h} - \headdecl{unistd.h} - - \funcdecl{int getgroups(int size, gid\_t list[])} - - Legge gli identificatori dei gruppi supplementari. - - \bodydesc{La funzione restituisce il numero di gruppi letti in caso di - successo e -1 in caso di fallimento, nel qual caso \var{errno} assumerà - i valori: - \begin{errlist} - \item[\errcode{EFAULT}] \param{list} non ha un indirizzo valido. - \item[\errcode{EINVAL}] il valore di \param{size} è diverso da zero ma - minore del numero di gruppi supplementari del processo. - \end{errlist}} -\end{functions} + +\begin{funcproto}{ +\fhead{sys/types.h} +\fhead{unistd.h} +\fdecl{int getgroups(int size, gid\_t list[])} +\fdesc{Legge gli identificatori dei gruppi supplementari.} +} +{La funzione ritorna il numero di gruppi letti in caso di successo e $-1$ per + un errore, nel qual caso \var{errno} assumerà uno dei valori: +\begin{errlist} +\item[\errcode{EFAULT}] \param{list} non ha un indirizzo valido. +\item[\errcode{EINVAL}] il valore di \param{size} è diverso da zero ma + minore del numero di gruppi supplementari del processo. +\end{errlist}} +\end{funcproto} La funzione legge gli identificatori dei gruppi supplementari del processo sul -vettore \param{list} di dimensione \param{size}. Non è specificato se la -funzione inserisca o meno nella lista il group-ID effettivo del processo. Se si -specifica un valore di \param{size} uguale a 0 \param{list} non viene -modificato, ma si ottiene il numero di gruppi supplementari. +vettore \param{list} che deve essere di dimensione pari a \param{size}. Non è +specificato se la funzione inserisca o meno nella lista il \acr{gid} effettivo +del processo. Se si specifica un valore di \param{size} uguale a $0$ allora +l'argomento \param{list} non viene modificato, ma si ottiene il numero di +gruppi supplementari. Una seconda funzione, \funcd{getgrouplist}, può invece essere usata per -ottenere tutti i gruppi a cui appartiene un certo utente; il suo prototipo è: -\begin{functions} - \headdecl{sys/types.h} - \headdecl{grp.h} - - \funcdecl{int getgrouplist(const char *user, gid\_t group, gid\_t *groups, - int *ngroups)} Legge i gruppi supplementari. - - \bodydesc{La funzione legge fino ad un massimo di \param{ngroups} valori, - restituisce 0 in caso di successo e -1 in caso di fallimento.} -\end{functions} - -La funzione legge i gruppi supplementari dell'utente specificato da -\param{user}, eseguendo una scansione del database dei gruppi (si veda -sez.~\ref{sec:sys_user_group}). Ritorna poi in \param{groups} la lista di -quelli a cui l'utente appartiene. Si noti che \param{ngroups} è passato come -puntatore perché, qualora il valore specificato sia troppo piccolo, la -funzione ritorna -1, passando indietro il numero dei gruppi trovati. - -Per impostare i gruppi supplementari di un processo ci sono due funzioni, che -possono essere usate solo se si hanno i privilegi di amministratore. La prima -delle due è \funcd{setgroups}, ed il suo prototipo è: -\begin{functions} - \headdecl{sys/types.h} - \headdecl{grp.h} - - \funcdecl{int setgroups(size\_t size, gid\_t *list)} - - Imposta i gruppi supplementari del processo. - - \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di - fallimento, nel qual caso \var{errno} assumerà i valori: - \begin{errlist} - \item[\errcode{EFAULT}] \param{list} non ha un indirizzo valido. - \item[\errcode{EPERM}] il processo non ha i privilegi di amministratore. - \item[\errcode{EINVAL}] il valore di \param{size} è maggiore del valore - massimo consentito. - \end{errlist}} -\end{functions} +ottenere tutti i gruppi a cui appartiene utente identificato per nome; il suo +prototipo è: + +\begin{funcproto}{ +\fhead{grp.h} +\fdecl{int getgrouplist(const char *user, gid\_t group, gid\_t *groups, int + *ngroups)} +\fdesc{Legge i gruppi cui appartiene un utente.} +} +{La funzione ritorna il numero di gruppi ottenuto in caso di successo e $-1$ + per un errore, che avviene solo quando il numero di gruppi è maggiore di + quelli specificati con \param{ngroups}.} +\end{funcproto} + +La funzione esegue una scansione del database dei gruppi (si veda +sez.~\ref{sec:sys_user_group}) per leggere i gruppi supplementari dell'utente +specificato per nome (e non con un \acr{uid}) nella stringa passata con +l'argomento \param{user}. Ritorna poi nel vettore \param{groups} la lista dei +\acr{gid} dei gruppi a cui l'utente appartiene. Si noti che \param{ngroups}, +che in ingresso deve indicare la dimensione di \param{group}, è passato come +\itindex{value~result~argument} \textit{value result argument} perché, qualora +il valore specificato sia troppo piccolo, la funzione ritorna $-1$, passando +comunque indietro il numero dei gruppi trovati, in modo da poter ripetere la +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{capability} + \textit{capability} \macro{CAP\_SETGID}.} La prima delle due è +\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 è: + +\begin{funcproto}{ +\fhead{grp.h} +\fdecl{int setgroups(size\_t size, gid\_t *list)} +\fdesc{Imposta i gruppi supplementari del processo.} +} +{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual +caso \var{errno} assumerà uno dei valori: +\begin{errlist} +\item[\errcode{EFAULT}] \param{list} non ha un indirizzo valido. +\item[\errcode{EPERM}] il processo non ha i privilegi di amministratore. +\item[\errcode{EINVAL}] il valore di \param{size} è maggiore del valore + massimo consentito di gruppi supplementari. +\end{errlist}} +\end{funcproto} La funzione imposta i gruppi supplementari del processo corrente ai valori specificati nel vettore passato con l'argomento \param{list}, di dimensioni -date dall'argomento \param{size}. Il numero massimo di gruppi supplementari è -un parametro di sistema, che può essere ricavato con le modalità spiegate in -sez.~\ref{sec:sys_characteristics}. +date dall'argomento \param{size}. Il numero massimo di gruppi supplementari +che si possono impostare è un parametro di sistema, che può essere ricavato +con le modalità spiegate in sez.~\ref{sec:sys_characteristics}. Se invece si vogliono impostare i gruppi supplementari del processo a quelli di un utente specifico, si può usare \funcd{initgroups} il cui prototipo è: -\begin{functions} - \headdecl{sys/types.h} - \headdecl{grp.h} - \funcdecl{int initgroups(const char *user, gid\_t group)} - - Inizializza la lista dei gruppi supplementari. - - \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di - fallimento, nel qual caso \var{errno} assumerà gli stessi valori di - \func{setgroups} più \errval{ENOMEM} quando non c'è memoria sufficiente - per allocare lo spazio per informazioni dei gruppi.} -\end{functions} +\begin{funcproto}{ +\fhead{sys/types.h} +\fhead{grp.h} +\fdecl{int initgroups(const char *user, gid\_t group)} +\fdesc{Inizializza la lista dei gruppi supplementari.} +} +{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual +caso \var{errno} assumerà uno dei valori: +\begin{errlist} +\item[\errcode{EPERM}] il processo non ha i privilegi di amministratore. +\item[\errcode{ENOMEM}] non c'è memoria sufficiente per allocare lo spazio per + informazioni dei gruppi. +\end{errlist}} +\end{funcproto} La funzione esegue la scansione del database dei gruppi (usualmente \conffile{/etc/group}) cercando i gruppi di cui è membro l'utente \param{user} -con cui costruisce una lista di gruppi supplementari, a cui aggiunge anche +(di nuovo specificato per nome e non per \acr{uid}) con cui costruisce una +lista di gruppi supplementari, a cui aggiunge anche \param{group}, infine imposta questa lista per il processo corrente usando \func{setgroups}. Si tenga presente che sia \func{setgroups} che \func{initgroups} non sono definite nello standard POSIX.1 e che pertanto non @@ -2261,11 +2300,12 @@ utilizzare.\footnote{nei processori moderni la presenza di ampie cache può un'altra, per cui effettuare la migliore scelta fra le diverse CPU non è banale.} Tutto questo comunque appartiene alle sottigliezze dell'implementazione del kernel; dal punto di vista dei programmi che girano -in user space, anche quando si hanno più processori (e dei processi che sono -eseguiti davvero in contemporanea), le politiche di scheduling riguardano -semplicemente l'allocazione della risorsa \textsl{tempo di esecuzione}, la cui -assegnazione sarà governata dai meccanismi di scelta delle priorità che -restano gli stessi indipendentemente dal numero di processori. +in \textit{user space}, anche quando si hanno più processori (e dei processi +che sono eseguiti davvero in contemporanea), le politiche di +\textit{scheduling} riguardano semplicemente l'allocazione della risorsa +\textsl{tempo di esecuzione}, la cui assegnazione sarà governata dai +meccanismi di scelta delle priorità che restano gli stessi indipendentemente +dal numero di processori. Si tenga conto poi che i processi non devono solo eseguire del codice: ad esempio molto spesso saranno impegnati in operazioni di I/O, o potranno @@ -2319,38 +2359,39 @@ fintanto che esso si trova in uno qualunque degli altri stati. Si deve quindi tenere presente che l'utilizzo della CPU è soltanto una delle risorse che sono necessarie per l'esecuzione di un programma, e a seconda -dello scopo del programma non è detto neanche che sia la più importante (molti -programmi dipendono in maniera molto più critica dall'I/O). Per questo motivo -non è affatto detto che dare ad un programma la massima priorità di esecuzione -abbia risultati significativi in termini di prestazioni. +dello scopo del programma non è detto neanche che sia la più importante, dato +che molti programmi dipendono in maniera molto più critica dall'I/O. Per +questo motivo non è affatto detto che dare ad un programma la massima priorità +di esecuzione abbia risultati significativi in termini di prestazioni. -Il meccanismo tradizionale di scheduling di Unix (che tratteremo in +Il meccanismo tradizionale di \textit{scheduling} di Unix (che tratteremo in sez.~\ref{sec:proc_sched_stand}) è sempre stato basato su delle \textsl{priorità dinamiche}, in modo da assicurare che tutti i processi, anche -i meno importanti, possano ricevere un po' di tempo di CPU. In sostanza quando -un processo ottiene la CPU la sua priorità viene diminuita. In questo modo -alla fine, anche un processo con priorità iniziale molto bassa, finisce per -avere una priorità sufficiente per essere eseguito. +i meno importanti, potessero ricevere un po' di tempo di CPU. In sostanza +quando un processo ottiene la CPU la sua priorità viene diminuita. In questo +modo alla fine, anche un processo con priorità iniziale molto bassa, finisce +per avere una priorità sufficiente per essere eseguito. Lo standard POSIX.1b però ha introdotto il concetto di \textsl{priorità assoluta}, (chiamata anche \textsl{priorità statica}, in contrapposizione alla normale priorità dinamica), per tenere conto dei sistemi -real-time,\footnote{per sistema real-time si intende un sistema in grado di - eseguire operazioni in un tempo ben determinato; in genere si tende a - distinguere fra l'\textit{hard real-time} in cui è necessario che i tempi di - esecuzione di un programma siano determinabili con certezza assoluta (come - nel caso di meccanismi di controllo di macchine, dove uno sforamento dei - tempi avrebbe conseguenze disastrose), e \textit{soft-real-time} in cui un - occasionale sforamento è ritenuto accettabile.} in cui è vitale che i -processi che devono essere eseguiti in un determinato momento non debbano -aspettare la conclusione di altri che non hanno questa necessità. +\textit{real-time},\footnote{per sistema \textit{real-time} si intende un + sistema in grado di eseguire operazioni in un tempo ben determinato; in + genere si tende a distinguere fra l'\textit{hard real-time} in cui è + necessario che i tempi di esecuzione di un programma siano determinabili con + certezza assoluta (come nel caso di meccanismi di controllo di macchine, + dove uno sforamento dei tempi avrebbe conseguenze disastrose), e + \textit{soft-real-time} in cui un occasionale sforamento è ritenuto + accettabile.} in cui è vitale che i processi che devono essere eseguiti in +un determinato momento non debbano aspettare la conclusione di altri che non +hanno questa necessità. Il concetto di priorità assoluta dice che quando due processi si contendono l'esecuzione, vince sempre quello con la priorità assoluta più alta. Ovviamente questo avviene solo per i processi che sono pronti per essere eseguiti (cioè nello stato \textit{runnable}). La priorità assoluta viene in genere indicata con un numero intero, ed un valore più alto comporta una -priorità maggiore. Su questa politica di scheduling torneremo in +priorità maggiore. Su questa politica di \textit{scheduling} torneremo in sez.~\ref{sec:proc_real_time}. In generale quello che succede in tutti gli Unix moderni è che ai processi @@ -2367,11 +2408,11 @@ bisogno della CPU. A meno che non si abbiano esigenze specifiche,\footnote{per alcune delle quali sono state introdotte delle varianti specifiche.} l'unico meccanismo di -scheduling con il quale si avrà a che fare è quello tradizionale, che prevede -solo priorità dinamiche. È di questo che, di norma, ci si dovrà preoccupare -nella programmazione. Come accennato in Linux i processi ordinari hanno tutti -una priorità assoluta nulla; quello che determina quale, fra tutti i processi -in attesa di esecuzione, sarà eseguito per primo, è la cosiddetta +\textit{scheduling} con il quale si avrà a che fare è quello tradizionale, che +prevede solo priorità dinamiche. È di questo che, di norma, ci si dovrà +preoccupare nella programmazione. Come accennato in Linux i processi ordinari +hanno tutti una priorità assoluta nulla; quello che determina quale, fra tutti +i processi in attesa di esecuzione, sarà eseguito per primo, è la cosiddetta \textsl{priorità dinamica},\footnote{quella che viene mostrata nella colonna \texttt{PR} del comando \texttt{top}.} che è chiamata così proprio perché varia nel corso dell'esecuzione di un processo. @@ -2388,7 +2429,7 @@ 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 \textbf{Runnable} +\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 @@ -2397,7 +2438,7 @@ ma non viene posto in esecuzione.\footnote{in realtà il calcolo della priorità 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 \textbf{Runnable}, quello che ha il valore di +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 @@ -2417,30 +2458,31 @@ priorità dinamica sono determinate dalla cosiddetta \textit{nice} (o 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 di \var{nice} nullo e nessuno è privilegiato rispetto agli altri; -specificando un valore positivo si avrà una \textit{time-slice} più breve ed +valore nullo e nessuno è privilegiato rispetto agli altri. Specificando un +valore di \textit{nice} positivo si avrà una \textit{time-slice} più breve ed un valore di priorità dinamica iniziale più alto, mentre un valore negativo darà una \textit{time-slice} più lunga ed un valore di priorità dinamica iniziale più basso. -Esistono diverse funzioni che consentono di modificare la \textit{niceness} di -un processo; la più semplice è funzione \funcd{nice}, che opera sul processo -corrente, il suo prototipo è: -\begin{prototype}{unistd.h} -{int nice(int inc)} - Aumenta il valore di \var{nice} per il processo corrente. - - \bodydesc{La funzione ritorna zero o il nuovo valore di \var{nice} in caso - di successo e -1 in caso di errore, nel qual caso \var{errno} può assumere - i valori: - \begin{errlist} +Esistono diverse funzioni che consentono di indicare un valore di +\textit{nice} di un processo; la più semplice è \funcd{nice}, che opera sul +processo corrente, il suo prototipo è: + +\begin{funcproto}{ +\fhead{unistd.h} +\fdecl{int nice(int inc)} +\fdesc{Aumenta il valore di \textit{nice} del processo corrente.} +} +{La funzione ritorna il nuovo valore di \textit{nice} in caso di successo e + $-1$ per un errore, nel qual caso \var{errno} assumerà uno dei valori: +\begin{errlist} \item[\errcode{EPERM}] non si ha il permesso di specificare un valore di \param{inc} negativo. - \end{errlist}} -\end{prototype} +\end{errlist}} +\end{funcproto} L'argomento \param{inc} indica l'incremento da effettuare rispetto al valore -di \var{nice} corrente: quest'ultimo può assumere valori compresi fra +di \textit{nice} corrente, che può assumere valori compresi fra \const{PRIO\_MIN} e \const{PRIO\_MAX}; nel caso di Linux sono fra $-20$ e $19$,\footnote{in realtà l'intervallo varia a seconda delle versioni di kernel, ed è questo a partire dal kernel 1.3.43, anche se oggi si può avere @@ -2448,21 +2490,22 @@ $19$,\footnote{in realtà l'intervallo varia a seconda delle versioni di 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 +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 più avanti) la priorità dei propri processi. +(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 \var{nice} del processo; tuttavia la \textit{system call} di Linux non -segue questa convenzione e restituisce sempre 0 in caso di successo e $-1$ in -caso di errore; questo perché $-1$ è un valore di \var{nice} legittimo e -questo comporta una confusione con una eventuale condizione di errore. La -\textit{system call} originaria inoltre non consente, se non dotati di -adeguati privilegi, di diminuire un valore di \var{nice} precedentemente +di \textit{nice} del processo; tuttavia la \textit{system call} di Linux non +segue questa convenzione e restituisce sempre $0$ in caso di successo e $-1$ +in caso di errore; questo perché $-1$ è anche un valore di \textit{nice} +legittimo e questo comporta una confusione con una eventuale condizione di +errore. La \textit{system call} originaria inoltre non consente, se non dotati +di adeguati privilegi, di diminuire un valore di \textit{nice} precedentemente innalzato. Fino alle \acr{glibc} 2.2.4 la funzione di libreria riportava direttamente il @@ -2471,7 +2514,7 @@ ottenere il nuovo valore occorreva una successiva chiamata alla funzione \func{getpriority}. A partire dalla \acr{glibc} 2.2.4 \func{nice} è stata reimplementata e non viene più chiamata la omonima \textit{system call}, con questa versione viene restituito come valore di ritorno il valore di -\var{nice}, come richiesto dallo standard.\footnote{questo viene fatto +\textit{nice}, come richiesto dallo standard.\footnote{questo viene fatto chiamando al suo interno \func{setpriority}, che tratteremo a breve.} In questo caso l'unico modo per rilevare in maniera affidabile una condizione di errore è quello di azzerare \var{errno} prima della chiamata della funzione e @@ -2479,28 +2522,36 @@ verificarne il valore quando \func{nice} restituisce $-1$. Per leggere il valore di \textit{nice} di un processo occorre usare la funzione \funcd{getpriority}, derivata da BSD; il suo prototipo è: -\begin{prototype}{sys/resource.h} -{int getpriority(int which, int who)} - -Restituisce il valore di \var{nice} per l'insieme dei processi specificati. - \bodydesc{La funzione ritorna la priorità in caso di successo e -1 in caso di - errore, nel qual caso \var{errno} può assumere i valori: - \begin{errlist} - \item[\errcode{ESRCH}] non c'è nessun processo che corrisponda ai valori di +\begin{funcproto}{ +\fhead{sys/time.h} +\fhead{sys/resource.h} +\fdecl{int getpriority(int which, int who)} +\fdesc{Legge un valore di \textit{nice}.} +} +{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual +caso \var{errno} assumerà uno dei valori: +\begin{errlist} +\item[\errcode{ESRCH}] non c'è nessun processo che corrisponda ai valori di \param{which} e \param{who}. - \item[\errcode{EINVAL}] il valore di \param{which} non è valido. - \end{errlist}} -\end{prototype} -\noindent nelle vecchie versioni può essere necessario includere anche -\file{}, questo non è più necessario con versioni recenti delle -librerie, ma è comunque utile per portabilità. - -La funzione permette, a seconda del valore di \param{which}, di leggere la -priorità di un processo, di un gruppo di processi (vedi -sez.~\ref{sec:sess_proc_group}) o di un utente, specificando un corrispondente -valore per \param{who} secondo la legenda di tab.~\ref{tab:proc_getpriority}; -un valore nullo di quest'ultimo indica il processo, il gruppo di processi o +\item[\errcode{EINVAL}] il valore di \param{which} non è uno di quelli + elencati in tab.~\ref{tab:proc_getpriority}. +\end{errlist}} +\end{funcproto} + +La funzione permette, a seconda di quanto specificato +nell'argomento \param{which}, di leggere il valore di \textit{nice} di un +processo, di un gruppo di processi (vedi sez.~\ref{sec:sess_proc_group}) o di +un utente indicato dall'argomento \param{who}. Nelle vecchie versioni può +essere necessario includere anche \code{sys/time.h}, questo non è più +necessario con versioni recenti delle librerie, ma è comunque utile per +portabilità. + +I valori possibili per \param{which}, ed il tipo di valore che occorre usare +in corrispondenza per \param{who} solo elencati nella legenda di +tab.~\ref{tab:proc_getpriority} insieme ai relativi significati. Usare un +valore nullo per \param{who} indica, a seconda della corrispondente +indicazione usata per \param{which} il processo, il gruppo di processi o l'utente correnti. \begin{table}[htb] @@ -2523,40 +2574,50 @@ l'utente correnti. \label{tab:proc_getpriority} \end{table} -La funzione restituisce la priorità più alta (cioè il valore più basso) fra -quelle dei processi specificati; di nuovo, dato che $-1$ è un valore -possibile, per poter rilevare una condizione di errore è necessario cancellare -sempre \var{errno} prima della chiamata alla funzione per verificare che essa +In caso di una indicazione che faccia riferimento a più processi, la funzione +restituisce la priorità più alta (cioè il valore più basso) fra quelle dei +processi corrispondenti. Come per \func{nice} $-1$ è un valore possibile +corretto, per cui di nuovo per poter rilevare una condizione di errore è +necessario cancellare sempre \var{errno} prima della chiamata alla funzione e +quando si ottiene un valore di ritorno uguale a $-1$ per verificare che essa resti uguale a zero. Analoga a \func{getpriority} è la funzione \funcd{setpriority} che permette di impostare la priorità di uno o più processi; il suo prototipo è: -\begin{prototype}{sys/resource.h} -{int setpriority(int which, int who, int prio)} - Imposta la priorità per l'insieme dei processi specificati. - \bodydesc{La funzione ritorna 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}] non c'è nessun processo che corrisponda ai valori di +\begin{funcproto}{ +\fhead{sys/time.h} +\fhead{sys/resource.h} +\fdecl{int setpriority(int which, int who, int prio)} +\fdesc{Imposta un valore di \textit{nice}.} +} +{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual +caso \var{errno} assumerà uno dei valori: +\begin{errlist} +\item[\errcode{ESRCH}] non c'è nessun processo che corrisponda ai valori di \param{which} e \param{who}. - \item[\errcode{EINVAL}] il valore di \param{which} non è valido. +\item[\errcode{EINVAL}] il valore di \param{which} non è uno di quelli + elencati in tab.~\ref{tab:proc_getpriority}. \item[\errcode{EACCES}] si è richiesto un aumento di priorità senza avere sufficienti privilegi. \item[\errcode{EPERM}] un processo senza i privilegi di amministratore ha cercato di modificare la priorità di un processo di un altro utente. - \end{errlist}} -\end{prototype} +\end{errlist}} +\end{funcproto} + +La funzione imposta la priorità dinamica al valore specificato da \param{prio} +per tutti i processi indicati dagli argomenti \param{which} e \param{who}, per +i quali valgono le stesse considerazioni fatte per \func{getpriority} e lo +specchietto di tab.~\ref{tab:proc_getpriority}. -La funzione imposta la priorità al valore specificato da \param{prio} per -tutti i processi indicati dagli argomenti \param{which} e \param{who}. In -questo caso come valore di \param{prio} deve essere specificato il valore di -\textit{nice} da assegnare, e non un incremento (positivo o negativo) come nel -caso di \func{nice}. La funzione restituisce il valore di \textit{nice} +In questo caso come valore di \param{prio} deve essere specificato il valore +di \textit{nice} da assegnare, e non un incremento (positivo o negativo) come +nel caso di \func{nice}, nell'intervallo fra \const{PRIO\_MIN} ($-20$) e +\const{PRIO\_MAX} ($19$). La funzione restituisce il valore di \textit{nice} assegnato in caso di successo e $-1$ in caso di errore, e come per \func{nice} anche in questo caso per rilevare un errore occorre sempre porre a zero \var{errno} prima della chiamata della funzione, essendo $-1$ un valore di -\textit{nice} valido. +\textit{nice} valido. Si tenga presente che solo l'amministratore\footnote{o più precisamente un processo con la \itindex{capabilities} \textit{capability} @@ -2565,12 +2626,12 @@ 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'user-ID reale o quello -effettivo del processo chiamante corrispondessero all'user-ID 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'user-ID effettivo. +sistemi derivati da SysV veniva richiesto che l'\acr{uid} reale o quello +effettivo del processo chiamante corrispondessero all'\acr{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'\acr{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 @@ -2579,26 +2640,39 @@ maniera indiscriminata, ed in particolare può essere effettuata solo nell'intervallo consentito dal valore del limite \const{RLIMIT\_NICE} (torneremo su questo in sez.~\ref{sec:sys_resource_limit}). +Infine nonostante i valori siano sempre rimasti gli stessi, il significato del +valore di \textit{nice} è cambiato parecchio nelle progressive riscritture +dello \textit{scheduler} di Linux, ed in particolare a partire dal kernel +2.6.23 l'uso di diversi valori di \textit{nice} ha un impatto molto più forte +nella distribuzione della CPU ai processi. Infatti se viene comunque calcolata +una priorità dinamica per i processi che non ricevono la CPU così che anche +essi possano essere messi in esecuzione, un alto valore di \textit{nice} +corrisponde comunque ad una \textit{time-slice} molto piccola che non cresce +comunque, per cui un processo a bassa priorità avra davvero scarse possibilità +di essere eseguito in presenza di processi attivi a priorità più alta. + + \subsection{Il meccanismo di \textit{scheduling real-time}} \label{sec:proc_real_time} Come spiegato in sez.~\ref{sec:proc_sched} lo standard POSIX.1b ha introdotto le priorità assolute per permettere la gestione di processi real-time. In -realtà nel caso di Linux non si tratta di un vero hard real-time, in quanto in -presenza di eventuali interrupt il kernel interrompe l'esecuzione di un -processo qualsiasi sia la sua priorità,\footnote{questo a meno che non si +realtà nel caso di Linux non si tratta di un vero \textit{hard real-time}, in +quanto in presenza di eventuali interrupt il kernel interrompe l'esecuzione di +un processo qualsiasi sia la sua priorità,\footnote{questo a meno che non si siano installate le patch di RTLinux, RTAI o Adeos, con i quali è possibile - ottenere un sistema effettivamente hard real-time. In tal caso infatti gli - interrupt vengono intercettati dall'interfaccia real-time (o nel caso di - 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 -\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. + ottenere un sistema effettivamente \textit{hard real-time}. In tal caso + infatti gli interrupt vengono intercettati dall'interfaccia + \textit{real-time} (o nel caso di 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 \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. Nonostante questo, ed in particolare con una serie di miglioramenti che sono stati introdotti nello sviluppo del kernel,\footnote{in particolare a partire @@ -2609,86 +2683,93 @@ stati introdotti nello sviluppo del kernel,\footnote{in particolare a partire essere fatto, ottenibili attivando in fase di compilazione una fra le opzioni \texttt{CONFIG\_PREEMPT\_NONE}, \texttt{CONFIG\_PREEMPT\_VOLUNTARY} e \texttt{CONFIG\_PREEMPT\_DESKTOP}.} si può arrivare ad una ottima -approssimazione di sistema real-time usando le priorità assolute; occorre -farlo però con molta attenzione: se si dà ad un processo una priorità assoluta -e questo finisce in un loop infinito, nessun altro processo potrà essere -eseguito, ed esso sarà mantenuto in esecuzione permanentemente assorbendo -tutta la CPU e senza nessuna possibilità di riottenere l'accesso al +approssimazione di sistema \textit{real-time} usando le priorità assolute. +Occorre farlo però con molta attenzione: se si dà ad un processo una priorità +assoluta e questo finisce in un loop infinito, nessun altro processo potrà +essere eseguito, ed esso sarà mantenuto in esecuzione permanentemente +assorbendo tutta la CPU e senza nessuna possibilità di riottenere l'accesso al sistema. Per questo motivo è sempre opportuno, quando si lavora con processi che usano priorità assolute, tenere attiva una shell cui si sia assegnata la massima priorità assoluta, in modo da poter essere comunque in grado di rientrare nel sistema. -Quando c'è un processo con priorità assoluta lo scheduler lo metterà in -esecuzione prima di ogni processo normale. In caso di più processi sarà +Quando c'è un processo con priorità assoluta lo \textit{scheduler} lo metterà +in esecuzione prima di ogni processo normale. In caso di più processi sarà eseguito per primo quello con priorità assoluta più alta. Quando ci sono più processi con la stessa priorità assoluta questi vengono tenuti in una coda e tocca al kernel decidere quale deve essere eseguito. Il meccanismo con cui -vengono gestiti questi processi dipende dalla politica di scheduling che si è -scelta; lo standard ne prevede due: +vengono gestiti questi processi dipende dalla politica di \textit{scheduling} +che si è scelta; lo standard ne prevede due: \begin{basedescript}{\desclabelwidth{1.2cm}\desclabelstyle{\nextlinelabel}} -\item[\textsf{FIFO}] \textit{First In First Out}. Il processo viene eseguito - fintanto che non cede volontariamente la CPU (con \func{sched\_yield}), si - blocca, finisce o viene interrotto da un processo a priorità più alta. Se il - processo viene interrotto da uno a priorità più alta esso resterà in cima - alla lista e sarà il primo ad essere eseguito quando i processi a priorità - più alta diverranno inattivi. Se invece lo si blocca volontariamente sarà - posto in coda alla lista (ed altri processi con la stessa priorità potranno - essere eseguiti). -\item[\textsf{RR}] \textit{Round Robin}. Il comportamento è del tutto analogo - a quello precedente, con la sola differenza che ciascun processo viene - eseguito al massimo per un certo periodo di tempo (la cosiddetta - \textit{time-slice}) dopo di che viene automaticamente posto in fondo alla - coda dei processi con la stessa priorità. In questo modo si ha comunque una - esecuzione a turno di tutti i processi, da cui il nome della politica. Solo - i processi con la stessa priorità ed in stato \textbf{Runnable} entrano nel +\item[\textit{First In First Out} (FIFO)] Il processo viene eseguito + fintanto che non cede volontariamente la CPU (con la funzione + \func{sched\_yield}), si blocca, finisce o viene interrotto da un processo a + priorità più alta. Se il processo viene interrotto da uno a priorità più + alta esso resterà in cima alla lista e sarà il primo ad essere eseguito + quando i processi a priorità più alta diverranno inattivi. Se invece lo si + blocca volontariamente sarà posto in coda alla lista (ed altri processi con + la stessa priorità potranno essere eseguiti). +\item[\textit{Round Robin} (RR)] Il comportamento è del tutto analogo a quello + precedente, con la sola differenza che ciascun processo viene eseguito al + massimo per un certo periodo di tempo (la cosiddetta \textit{time-slice}) + dopo di che viene automaticamente posto in fondo alla coda dei processi con + la stessa priorità. In questo modo si ha comunque una esecuzione a turno di + tutti i processi, da cui il nome della politica. Solo i processi con la + stessa priorità ed in stato \textit{runnable} entrano nel \textsl{girotondo}. \end{basedescript} Lo standard POSIX.1-2001 prevede una funzione che consenta sia di modificare -le politiche di scheduling, passando da real-time a ordinarie o viceversa, che -di specificare, in caso di politiche real-time, la eventuale priorità statica; -la funzione è \funcd{sched\_setscheduler} ed il suo prototipo è: -\begin{prototype}{sched.h} -{int sched\_setscheduler(pid\_t pid, int policy, const struct sched\_param *p)} - Imposta priorità e politica di scheduling. - - \bodydesc{La funzione ritorna 0 in caso di successo e $-$1 in caso di - errore, nel qual caso \var{errno} può assumere i valori: - \begin{errlist} +le politiche di \textit{scheduling}, passando da \textit{real-time} a +ordinarie o viceversa, che di specificare, in caso di politiche +\textit{real-time}, la eventuale priorità statica; la funzione è +\funcd{sched\_setscheduler} ed il suo prototipo è: + +\begin{funcproto}{ +\fhead{sched.h} +\fdecl{int sched\_setscheduler(pid\_t pid, int policy, const struct + sched\_param *p)} +\fdesc{Imposta priorità e politica di \textit{scheduling}.} +} +{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual +caso \var{errno} assumerà uno dei valori: +\begin{errlist} \item[\errcode{ESRCH}] il processo \param{pid} non esiste. \item[\errcode{EINVAL}] il valore di \param{policy} non esiste o il - relativo valore di \param{p} non è valido. + relativo valore di \param{p} non è valido per la politica scelta. \item[\errcode{EPERM}] il processo non ha i privilegi per attivare la politica richiesta. - \end{errlist}} -\end{prototype} + \end{errlist}} +\end{funcproto} La funzione esegue l'impostazione per il processo specificato dall'argomento -\param{pid}; un valore nullo di questo argomento esegue l'impostazione per il -processo corrente. La politica di scheduling è specificata +\param{pid}, un valore nullo di questo argomento esegue l'impostazione per il +processo corrente. La politica di \textit{scheduling} è specificata dall'argomento \param{policy} i cui possibili valori sono riportati in tab.~\ref{tab:proc_sched_policy}; la parte alta della tabella indica le -politiche real-time, quella bassa le politiche ordinarie. Un valore negativo -per \param{policy} mantiene la politica di scheduling corrente. +politiche \textit{real-time}, quella bassa le politiche ordinarie. Un valore +negativo per \param{policy} mantiene la politica di \textit{scheduling} +corrente. \begin{table}[htb] \centering \footnotesize - \begin{tabular}[c]{|l|l|} + \begin{tabular}[c]{|l|p{6cm}|} \hline - \textbf{Policy} & \textbf{Significato} \\ + \textbf{Politica} & \textbf{Significato} \\ \hline \hline - \const{SCHED\_FIFO} & Scheduling real-time con politica \textit{FIFO}. \\ - \const{SCHED\_RR} & Scheduling real-time con politica \textit{Round - Robin}. \\ + \const{SCHED\_FIFO} & \textit{Scheduling real-time} con politica + \textit{FIFO}. \\ + \const{SCHED\_RR} & \textit{Scheduling real-time} con politica + \textit{Round Robin}. \\ \hline - \const{SCHED\_OTHER}& Scheduling ordinario.\\ - \const{SCHED\_BATCH}& Scheduling ordinario con l'assunzione ulteriore di - lavoro \textit{CPU intensive}.\footnotemark\\ - \const{SCHED\_IDLE} & Scheduling di priorità estremamente - bassa.\footnotemark\\ + \const{SCHED\_OTHER}& \textit{Scheduling} ordinario.\\ + \const{SCHED\_BATCH}& \textit{Scheduling} ordinario con l'assunzione + ulteriore di lavoro \textit{CPU + intensive} (dal kernel 2.6.16)\\ + \const{SCHED\_IDLE} & \textit{Scheduling} di priorità estremamente + bassa (dal kernel 2.6.23)\\ \hline \end{tabular} \caption{Valori dell'argomento \param{policy} per la funzione @@ -2696,19 +2777,16 @@ per \param{policy} mantiene la politica di scheduling corrente. \label{tab:proc_sched_policy} \end{table} -\footnotetext[44]{introdotto con il kernel 2.6.16.} -\footnotetext{introdotto con il kernel 2.6.23.} - Con le versioni più recenti del kernel sono state introdotte anche delle -varianti sulla politica di scheduling tradizionale per alcuni carichi di -lavoro specifici, queste due nuove politiche sono specifiche di Linux e non +varianti sulla politica di \textit{scheduling} tradizionale per alcuni carichi +di lavoro specifici, queste due nuove politiche sono specifiche di Linux e non 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 -\textbf{Sleep}.\footnote{cosa che accade con grande frequenza per i processi +\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 @@ -2724,13 +2802,14 @@ da fare. Va comunque sottolineato che anche un processo \const{SCHED\_IDLE} avrà comunque una sua possibilità di utilizzo della CPU, sia pure in percentuale molto bassa. -Qualora si sia richiesta una politica real-time il valore della priorità -statica viene impostato attraverso la struttura \struct{sched\_param}, -riportata in fig.~\ref{fig:sig_sched_param}, il cui solo campo attualmente -definito è \var{sched\_priority}. Il campo deve contenere il valore della -priorità statica da assegnare al processo; lo standard prevede che questo -debba essere assegnato all'interno di un intervallo fra un massimo ed un -minimo che nel caso di Linux sono rispettivamente 1 e 99. +Qualora si sia richiesta una politica \textit{real-time} il valore della +priorità statica viene impostato attraverso la struttura +\struct{sched\_param}, riportata in fig.~\ref{fig:sig_sched_param}, il cui +solo campo attualmente definito è \var{sched\_priority}. Il campo deve +contenere il valore della priorità statica da assegnare al processo; lo +standard prevede che questo debba essere assegnato all'interno di un +intervallo fra un massimo ed un minimo che nel caso di Linux sono +rispettivamente 1 e 99. \begin{figure}[!htbp] \footnotesize \centering @@ -2742,43 +2821,44 @@ minimo che nel caso di Linux sono rispettivamente 1 e 99. \label{fig:sig_sched_param} \end{figure} -I processi con politica di scheduling ordinaria devono sempre specificare un -valore nullo di \var{sched\_priority} altrimenti si avrà un errore -\errcode{EINVAL}, questo valore infatti non ha niente a che vedere con la -priorità dinamica determinata dal valore di \textit{nice}, che deve essere +I processi con politica di \textit{scheduling} ordinaria devono sempre +specificare un valore nullo di \var{sched\_priority} altrimenti si avrà un +errore \errcode{EINVAL}, questo valore infatti non ha niente a che vedere con +la priorità dinamica determinata dal valore di \textit{nice}, che deve essere impostato con le funzioni viste in precedenza. -Lo standard POSIX.1b prevede comunque che i due valori della massima e minima -priorità statica possano essere ottenuti, per ciascuna delle politiche di -scheduling \textit{real-time}, tramite le due funzioni +Lo standard POSIX.1b prevede comunque che l'intervallo dei valori delle +priorità statiche possa essere ottenuto tramite le due funzioni \funcd{sched\_get\_priority\_max} e \funcd{sched\_get\_priority\_min}, i cui prototipi sono: -\begin{functions} - \headdecl{sched.h} - - \funcdecl{int sched\_get\_priority\_max(int policy)} Legge il valore - massimo della priorità statica per la politica di scheduling \param{policy}. - - \funcdecl{int sched\_get\_priority\_min(int policy)} Legge il valore minimo - della priorità statica per la politica di scheduling \param{policy}. - - \bodydesc{La funzioni ritornano il valore della priorità in caso di successo - e $-1$ in caso di errore, nel qual caso \var{errno} può assumere i valori: - \begin{errlist} - \item[\errcode{EINVAL}] il valore di \param{policy} non è valido. - \end{errlist}} -\end{functions} +\begin{funcproto}{ +\fhead{sched.h} +\fdecl{int sched\_get\_priority\_max(int policy)} +\fdesc{Legge il valore massimo di una priorità statica.} +\fdecl{int sched\_get\_priority\_min(int policy)} +\fdesc{Legge il valore minimo di una priorità statica.} +} +{Le funzioni ritornano il valore della priorità in caso di successo e $-1$ per + un errore, nel qual caso \var{errno} assumerà il valore: +\begin{errlist} +\item[\errcode{EINVAL}] il valore di \param{policy} non è valido. +\end{errlist}} +\end{funcproto} + +Le funzioni ritornano rispettivamente i due valori della massima e minima +priorità statica possano essere ottenuti per una delle politiche di +\textit{scheduling} \textit{real-time} indicata dall'argomento \param{policy}. -Si tenga presente che quando si imposta una politica di scheduling real-time -per un processo o se ne cambia la priorità statica questo viene messo in cima -alla lista dei processi con la stessa priorità; questo comporta che verrà -eseguito subito, interrompendo eventuali altri processi con la stessa priorità -in quel momento in esecuzione. +Si tenga presente che quando si imposta una politica di \textit{scheduling} +real-time per un processo o se ne cambia la priorità statica questo viene +messo in cima alla lista dei processi con la stessa priorità; questo comporta +che verrà eseguito subito, interrompendo eventuali altri processi con la +stessa priorità in quel momento in esecuzione. Il kernel mantiene i processi con la stessa priorità assoluta in una lista, ed esegue sempre il primo della lista, mentre un nuovo processo che torna in -stato \textbf{Runnable} viene sempre inserito in coda alla lista. Se la +stato \textit{runnable} viene sempre inserito in coda alla lista. Se la politica scelta è \const{SCHED\_FIFO} quando il processo viene eseguito viene automaticamente rimesso in coda alla lista, e la sua esecuzione continua fintanto che non viene bloccato da una richiesta di I/O, o non rilascia @@ -2791,150 +2871,181 @@ Solo un processo con i privilegi di amministratore\footnote{più precisamente 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 -processi che gli appartengono; è cioè richiesto che l'user-ID effettivo del -processo chiamante corrisponda all'user-ID reale o effettivo del processo +processi che gli appartengono; è cioè richiesto che l'\acr{uid} effettivo del +processo chiamante corrisponda all'\acr{uid} reale o effettivo del processo indicato con \param{pid}. Fino al kernel 2.6.12 gli utenti normali non potevano impostare politiche -real-time o modificare la eventuale priorità statica di un loro processo. A -partire da questa versione è divenuto possibile anche per gli utenti normali -usare politiche real-time fintanto che la priorità assoluta che si vuole -impostare è inferiore al limite \const{RLIMIT\_RTPRIO} (vedi -sez.~\ref{sec:sys_resource_limit}) ad essi assegnato. Unica eccezione a questa -possibilità sono i processi \const{SCHED\_IDLE}, che non possono cambiare -politica di scheduling indipendentemente dal valore di -\const{RLIMIT\_RTPRIO}. Inoltre, in caso di processo già sottoposto ad una -politica real-time, un utente può sempre, indipendentemente dal valore di -\const{RLIMIT\_RTPRIO}, diminuirne la priorità o portarlo ad una politica -ordinaria. +\textit{real-time} o modificare la eventuale priorità statica di un loro +processo. A partire da questa versione è divenuto possibile anche per gli +utenti normali usare politiche \textit{real-time} fintanto che la priorità +assoluta che si vuole impostare è inferiore al limite \const{RLIMIT\_RTPRIO} +(vedi sez.~\ref{sec:sys_resource_limit}) ad essi assegnato. + +Unica eccezione a questa possibilità sono i processi \const{SCHED\_IDLE}, che +non possono cambiare politica di \textit{scheduling} indipendentemente dal +valore di \const{RLIMIT\_RTPRIO}. Inoltre, in caso di processo già sottoposto +ad una politica \textit{real-time}, un utente può sempre, indipendentemente +dal valore di \const{RLIMIT\_RTPRIO}, diminuirne la priorità o portarlo ad una +politica ordinaria. Se si intende operare solo sulla priorità statica di un processo si possono usare le due funzioni \funcd{sched\_setparam} e \funcd{sched\_getparam} che consentono rispettivamente di impostarne e leggerne il valore, i loro prototipi sono: -\begin{functions} - \headdecl{sched.h} - \funcdecl{int sched\_setparam(pid\_t pid, const struct sched\_param *param)} - Imposta la priorità statica del processo \param{pid}. - - \funcdecl{int sched\_getparam(pid\_t pid, struct sched\_param *param)} - Legge la priorità statica del processo \param{pid}. +\begin{funcproto}{ +\fhead{sched.h} +\fdecl{int sched\_setparam(pid\_t pid, const struct sched\_param *param)} +\fdesc{Imposta la priorità statica di un processo.} +\fdecl{int sched\_getparam(pid\_t pid, struct sched\_param *param)} +\fdesc{Legge la priorità statica di un processo.} +} +{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual +caso \var{errno} assumerà uno dei valori: +\begin{errlist} +\item[\errcode{ESRCH}] il processo \param{pid} non esiste. +\item[\errcode{EINVAL}] il valore di \param{param} non ha senso per la + politica usata dal processo. +\item[\errcode{EPERM}] non si hanno privilegi sufficienti per eseguire + l'operazione. +\end{errlist}} +\end{funcproto} - \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}] il processo \param{pid} non esiste. - \item[\errcode{EINVAL}] il valore di \param{param} non ha senso per la - politica usata dal processo. - \item[\errcode{EPERM}] non si hanno privilegi sufficienti per eseguire - l'operazione. - \end{errlist}} -\end{functions} +Le funzioni richiedono di indicare nell'argomento \param{pid} il processo su +cui operare e usano l'argomento \param{param} per mantenre il valore della +priorità dinamica. Questo è ancora una struttura \struct{sched\_param} ed +assume gli stessi valori già visti per \func{sched\_setscheduler}. L'uso di \func{sched\_setparam}, compresi i controlli di accesso che vi si applicano, è del tutto equivalente a quello di \func{sched\_setscheduler} con -argomento \param{policy} uguale a -1. Come per \func{sched\_setscheduler} -specificando 0 come valore dell'argomento \param{pid} si opera sul processo +argomento \param{policy} uguale a $-1$. Come per \func{sched\_setscheduler} +specificando $0$ come valore dell'argomento \param{pid} si opera sul processo corrente. Benché la funzione sia utilizzabile anche con processi sottoposti a -politica ordinaria essa ha senso soltanto per quelli real-time, dato che per i -primi la priorità statica può essere soltanto nulla. La disponibilità di -entrambe le funzioni può essere verificata controllando la macro -\macro{\_POSIX\_PRIORITY\_SCHEDULING} che è definita nell'header -\file{sched.h}. - -Se invece si vuole sapere quale è politica di scheduling di un processo si può -usare la funzione \funcd{sched\_getscheduler}, il cui prototipo è: -\begin{prototype}{sched.h} -{int sched\_getscheduler(pid\_t pid)} - Legge la politica di scheduling per il processo \param{pid}. - - \bodydesc{La funzione ritorna la politica di scheduling in caso di successo - e $-1$ in caso di errore, nel qual caso \var{errno} può assumere i valori: - \begin{errlist} +politica ordinaria essa ha senso soltanto per quelli \textit{real-time}, dato +che per i primi la priorità statica può essere soltanto nulla. La +disponibilità di entrambe le funzioni può essere verificata controllando la +macro \macro{\_POSIX\_PRIORITY\_SCHEDULING} che è definita nell'\textit{header + file} \file{sched.h}. + +Se invece si vuole sapere quale è politica di \textit{scheduling} di un +processo si può usare la funzione \funcd{sched\_getscheduler}, il cui +prototipo è: + +\begin{funcproto}{ +\fhead{sched.h} +\fdecl{int sched\_getscheduler(pid\_t pid)} +\fdesc{Legge la politica di \textit{scheduling}.} +} +{La funzione ritorna la politica di \textit{scheduling} in caso di successo e + $-1$ per un errore, nel qual caso \var{errno} assumerà uno dei valori: +\begin{errlist} \item[\errcode{ESRCH}] il processo \param{pid} non esiste. \item[\errcode{EPERM}] non si hanno privilegi sufficienti per eseguire l'operazione. - \end{errlist}} -\end{prototype} +\end{errlist}} +\end{funcproto} La funzione restituisce il valore, secondo quanto elencato in -tab.~\ref{tab:proc_sched_policy}, della politica di scheduling per il processo -specificato; se l'argomento \param{pid} è nullo viene restituito il valore -relativo al processo chiamante. +tab.~\ref{tab:proc_sched_policy}, della politica di \textit{scheduling} per il +processo specificato dall'argomento \param{pid}, se questo è nullo viene +restituito il valore relativo al processo chiamante. L'ultima funzione che permette di leggere le informazioni relative ai processi real-time è \funcd{sched\_rr\_get\_interval}, che permette di ottenere la lunghezza della \textit{time-slice} usata dalla politica \textit{round robin}; il suo prototipo è: -\begin{prototype}{sched.h} - {int sched\_rr\_get\_interval(pid\_t pid, struct timespec *tp)} Legge in - \param{tp} la durata della \textit{time-slice} per il processo \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: - \begin{errlist} - \item[\errcode{ESRCH}] il processo \param{pid} non esiste. - \item[\errcode{ENOSYS}] la \textit{system call} non è stata implementata. - \end{errlist}} -\end{prototype} -La funzione restituisce il valore dell'intervallo di tempo usato per la -politica \textit{round robin} in una struttura \struct{timespec}, (la cui -definizione si può trovare in fig.~\ref{fig:sys_timeval_struct}). In realtà -dato che in Linux questo intervallo di tempo è prefissato e non modificabile, -questa funzione ritorna sempre un valore di 150 millisecondi, e non importa -specificare il PID di un processo reale. +\begin{funcproto}{ +\fhead{sched.h} +\fdecl{int sched\_rr\_get\_interval(pid\_t pid, struct timespec *tp)} +\fdesc{Legge la durata della \textit{time-slice} per lo \textit{scheduling} + \textit{round robin}.} +} +{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual +caso \var{errno} assumerà uno dei valori: +\begin{errlist} +\item[\errcode{ESRCH}] il processo \param{pid} non esiste. +\item[\errcode{EINVAL}] l'argomento \param{pid} non è valido. +\item[\errcode{ENOSYS}] la \textit{system call} non è presente (solo per + kernel arcaici). +\end{errlist} +ed inoltre anche \errval{EFAULT} nel suo significato generico.} +\end{funcproto} + +La funzione restituisce nell'argomento \param{tp} come una struttura +\struct{timespec}, (la cui definizione si può trovare in +fig.~\ref{fig:sys_timeval_struct}) il valore dell'intervallo di tempo usato +per la politica \textit{round robin} dal processo indicato da \acr{pid}. Il +valore dipende dalla versione del kernel, a lungo infatti questo intervallo di +tempo era prefissato e non modificabile ad un valore di 150 millisecondi, +restituito indipendentemente dal \acr{pid} indicato. + +Con kernel recenti però è possibile ottenere una variazione della +\textit{time-slice}, modificando il valore di \textit{nice} del processo +(anche se questo non incide assolutamente sulla priorità statica) che come +accennato in precedenza modifica il valore assegnato alla \textit{time-slice} +di un processo ordinario, che però viene usato anche dai processi +\textit{real-time}. Come accennato ogni processo può rilasciare volontariamente la CPU in modo da consentire agli altri processi di essere eseguiti; la funzione che consente di fare tutto ciò è \funcd{sched\_yield}, il cui prototipo è: -\begin{prototype}{sched.h} - {int sched\_yield(void)} - - Rilascia volontariamente l'esecuzione. - - \bodydesc{La funzione ritorna 0 in caso di successo e -1 in caso di errore, - nel qual caso \var{errno} viene impostata opportunamente.} -\end{prototype} - -Questa funzione ha un utilizzo effettivo soltanto quando si usa lo scheduling -real-time, e serve a far sì che il processo corrente rilasci la CPU, in modo -da essere rimesso in coda alla lista dei processi con la stessa priorità per -permettere ad un altro di essere eseguito; se però il processo è l'unico ad -essere presente sulla coda l'esecuzione non sarà interrotta. In genere usano -questa funzione i processi con politica \const{SCHED\_FIFO}, per permettere -l'esecuzione degli altri processi con pari priorità quando la sezione più -urgente è finita. - -La funzione può essere utilizzata anche con processi che usano lo scheduling -ordinario, ma in questo caso il comportamento non è ben definito, e dipende -dall'implementazione. Fino al kernel 2.6.23 questo comportava che i processi -venissero messi in fondo alla coda di quelli attivi, con la possibilità di -essere rimessi in esecuzione entro breve tempo, con l'introduzione del -\textit{Completely Fair Scheduler} questo comportamento è cambiato ed un -processo che chiama la funzione viene inserito nella lista dei processi -inattivo, con un tempo molto maggiore.\footnote{è comunque possibile + +\begin{funcproto}{ +\fhead{sched.h} +\fdecl{int sched\_yield(void)} +\fdesc{Rilascia volontariamente l'esecuzione.} +} +{La funzione ritorna $0$ in caso di successo e teoricamente $-1$ per un + errore, ma su Linux ha sempre successo.} +\end{funcproto} + + +Questa funzione ha un utilizzo effettivo soltanto quando si usa lo +\textit{scheduling} \textit{real-time}, e serve a far sì che il processo +corrente rilasci la CPU, in modo da essere rimesso in coda alla lista dei +processi con la stessa priorità per permettere ad un altro di essere eseguito; +se però il processo è l'unico ad essere presente sulla coda l'esecuzione non +sarà interrotta. In genere usano questa funzione i processi con politica +\const{SCHED\_FIFO}, per permettere l'esecuzione degli altri processi con pari +priorità quando la sezione più urgente è finita. + +La funzione può essere utilizzata anche con processi che usano lo +\textit{scheduling} ordinario, ma in questo caso il comportamento non è ben +definito, e dipende dall'implementazione. Fino al kernel 2.6.23 questo +comportava che i processi venissero messi in fondo alla coda di quelli attivi, +con la possibilità di essere rimessi in esecuzione entro breve tempo, con +l'introduzione del \textit{Completely Fair Scheduler} questo comportamento è +cambiato ed un processo che chiama la funzione viene inserito nella lista dei +processi inattivo, con un tempo molto maggiore.\footnote{è comunque possibile ripristinare un comportamento analogo al precedente scrivendo il valore 1 nel file \texttt{/proc/sys/kernel/sched\_compat\_yield}.} +L'uso delle funzione nella programmazione ordinaria può essere utile e +migliorare le prestazioni generali del sistema quando si è appena rilasciata +una risorsa contesa con altri processi, e si vuole dare agli altri una +possibilità di approfittarne mettendoli in esecuzione, ma chiamarla senza +necessità, specie se questo avviene ripetutamente all'interno di un qualche +ciclo, può avere invece un forte impatto negativo per la generazione di +\itindex{contest~switch} \textit{contest switch} inutili. \subsection{Il controllo dello \textit{scheduler} per i sistemi multiprocessore} \label{sec:proc_sched_multiprocess} -Infine con il supporto dei sistemi multiprocessore sono state introdotte delle +Con il supporto dei sistemi multiprocessore sono state introdotte delle 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 del cosiddetto \index{effetto~ping-pong} \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 processo -passa da un processore all'altro in questo modo (cosa che avveniva abbastanza -di frequente con i kernel della seria 2.4.x) si ha l'\textsl{effetto - ping-pong}. +\textit{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 processo passa da un processore all'altro in questo modo, +cosa che avveniva abbastanza di frequente con i kernel della seria 2.4.x, si +ha l'\textsl{effetto ping-pong}. Questo tipo di comportamento può generare dei seri problemi di prestazioni; infatti tutti i processori moderni utilizzano una memoria interna (la @@ -2959,58 +3070,60 @@ disponibile. 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 l'esecuzione sempre allo stesso -processore. Lo scheduler dei kernel della serie 2.4.x aveva una scarsa -\textit{CPU affinity}, e \index{effetto~ping-pong} l'effetto ping-pong era -comune; con il nuovo scheduler dei kernel della 2.6.x questo problema è stato -risolto ed esso cerca di mantenere il più possibile ciascun processo sullo -stesso processore. +processore. Lo \textit{scheduler} dei kernel della serie 2.4.x aveva una +scarsa \textit{CPU affinity}, e \index{effetto~ping-pong} l'effetto ping-pong +era comune; con il nuovo \textit{scheduler} dei kernel della 2.6.x questo +problema è stato risolto ed esso cerca di mantenere il più possibile ciascun +processo sullo stesso processore. In certi casi però resta l'esigenza di poter essere sicuri che un processo sia sempre eseguito dallo stesso processore,\footnote{quella che viene detta - \textit{hard CPU affinity}, in contrasto con quella fornita dallo scheduler, - detta \textit{soft CPU affinity}, che di norma indica solo una preferenza, - non un requisito assoluto.} e per poter risolvere questo tipo di -problematiche nei nuovi kernel\footnote{le due \textit{system call} per la - gestione della \textit{CPU affinity} sono state introdotte nel kernel 2.5.8, - e le funzioni di libreria nelle \textsl{glibc} 2.3.} è stata introdotta -l'opportuna infrastruttura ed una nuova \textit{system call} che permette di -impostare su quali processori far eseguire un determinato processo attraverso -una \textsl{maschera di affinità}. La corrispondente funzione di libreria è -\funcd{sched\_setaffinity} ed il suo prototipo è: -\begin{prototype}{sched.h} - {int sched\_setaffinity (pid\_t pid, unsigned int cpusetsize, const - cpu\_set\_t *cpuset)} - Imposta la maschera di affinità del processo \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: - \begin{errlist} - \item[\errcode{ESRCH}] il processo \param{pid} non esiste. - \item[\errcode{EINVAL}] il valore di \param{cpuset} contiene riferimenti a - processori non esistenti nel sistema. - \item[\errcode{EPERM}] il processo non ha i privilegi sufficienti per - eseguire l'operazione. - \end{errlist} - ed inoltre anche \errval{EFAULT}.} -\end{prototype} + \textit{hard CPU affinity}, in contrasto con quella fornita dallo + \textit{scheduler}, detta \textit{soft CPU affinity}, che di norma indica + solo una preferenza, non un requisito assoluto.} e per poter risolvere +questo tipo di problematiche nei nuovi kernel\footnote{le due \textit{system + call} per la gestione della \textit{CPU affinity} sono state introdotte + nel kernel 2.5.8, e le funzioni di libreria nelle \textsl{glibc} 2.3.} è +stata introdotta l'opportuna infrastruttura ed una nuova \textit{system call} +che permette di impostare su quali processori far eseguire un determinato +processo attraverso una \textsl{maschera di affinità}. La corrispondente +funzione di libreria è \funcd{sched\_setaffinity} ed il suo prototipo è: +\begin{funcproto}{ +\fhead{sched.h} +\fdecl{int sched\_setaffinity (pid\_t pid, size\_t cpusetsize, + cpu\_set\_t *mask)} +\fdesc{Imposta la maschera di affinità di un processo.} +} +{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual +caso \var{errno} assumerà uno dei valori: +\begin{errlist} +\item[\errcode{ESRCH}] il processo \param{pid} non esiste. +\item[\errcode{EINVAL}] il valore di \param{mask} contiene riferimenti a + processori non esistenti nel sistema o a cui non è consentito l'accesso. +\item[\errcode{EPERM}] il processo non ha i privilegi sufficienti per + eseguire l'operazione. +\end{errlist} +ed inoltre anche \errval{EFAULT} nel suo significato generico.} +\end{funcproto} Questa funzione e la corrispondente \func{sched\_setaffinity} hanno una storia -abbastanza complessa, la \textit{system call} prevede l'uso di due ulteriori -argomenti di tipo \texttt{unsigned int len} e \texttt{unsigned long *mask}, -che corrispondono al fatto che la implementazione effettiva usa una semplice -maschera binaria. Quando le funzioni vennero incluse nelle \acr{glibc} -assunsero invece il prototipo appena mostrato. A complicare la cosa si -aggiunge il fatto che nella versione 2.3.3 delle \acr{glibc} l'argomento -\param{cpusetsize} è stato eliminato, per poi essere ripristinato nella -versione 2.3.4.\footnote{pertanto se la vostra pagina di manuale non è +abbastanza complessa, la sottostante \textit{system call} infatti prevede +l'uso di due soli argomenti (per il pid e l'indicazione della maschera dei +processori), che corrispondono al fatto che l'implementazione effettiva usa +una semplice maschera binaria. Quando le funzioni vennero incluse nelle +\acr{glibc} assunsero invece un prototipo simile a quello mostrato però con il +secondo argomento di tipo \ctyp{unsigned int}. A complicare la cosa si +aggiunge il fatto che nella versione 2.3.3 delle \acr{glibc} detto argomento +venne stato eliminato, per poi essere ripristinato nella versione 2.3.4 nella +forma attuale.\footnote{pertanto se la vostra pagina di manuale non è aggiornata, o usate quella particolare versione delle \acr{glibc}, potrete trovare indicazioni diverse, il prototipo illustrato è quello riportato nella versione corrente (maggio 2008) delle pagine di manuale e corrispondente alla definizione presente in \file{sched.h}.} La funzione imposta, con l'uso del valore contenuto all'indirizzo -\param{cpuset}, l'insieme dei processori sui quali deve essere eseguito il +\param{mask}, l'insieme dei processori sui quali deve essere eseguito il processo identificato tramite il valore passato in \param{pid}. Come in precedenza il valore nullo di \param{pid} indica il processo corrente. Per poter utilizzare questa funzione sono richiesti i privilegi di amministratore @@ -3024,12 +3137,13 @@ Nell'uso comune, almeno con i kernel della 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 real-time o -la cui risposta è critica) e si vuole la massima velocità, con questa -interfaccia diventa possibile selezionare gruppi di processori utilizzabili in -maniera esclusiva. Lo stesso dicasi quando l'accesso a certe risorse (memoria -o periferiche) può avere un costo diverso a seconda del processore, come -avviene nelle architetture NUMA (\textit{Non-Uniform Memory Access}). +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 +l'accesso a certe risorse (memoria o periferiche) può avere un costo diverso a +seconda del processore, come avviene nelle architetture NUMA +(\textit{Non-Uniform Memory Access}). Infine se un gruppo di processi accede alle stesse risorse condivise (ad esempio una applicazione con più \itindex{thread} \textit{thread}) può avere @@ -3041,72 +3155,84 @@ serializzati nell'accesso ad una risorsa) possono esserci sufficienti vantaggi nell'evitare la perdita della cache da rendere conveniente l'uso dell'affinità di processore. -Per facilitare l'uso dell'argomento \param{cpuset} le \acr{glibc} hanno +Per facilitare l'uso dell'argomento \param{mask} le \acr{glibc} hanno introdotto un apposito dato di tipo, \type{cpu\_set\_t},\footnote{questa è una estensione specifica delle \acr{glibc}, da attivare definendo la macro - \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 -corrisponde ad un processore, ma dato che per architetture particolari il -numero di bit di un intero può non essere sufficiente, è stata creata questa -che è una interfaccia generica che permette di usare a basso livello un tipo -di dato qualunque rendendosi indipendenti dal numero di bit e dalla loro -disposizione. + \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 corrisponde ad un +processore, ma dato che per architetture particolari il numero di bit di un +intero può non essere sufficiente, è stata creata questa che è una interfaccia +generica che permette di usare a basso livello un tipo di dato qualunque +rendendosi indipendenti dal numero di bit e dalla loro disposizione. Questa interfaccia, oltre alla definizione del tipo di dato apposito, prevede anche una serie di macro di preprocessore per la manipolazione dello stesso, che consentono di svuotare un insieme, aggiungere o togliere un processore da esso o verificare se vi è già presente: -\begin{functions} - \headdecl{sched.h} - \funcdecl{void \macro{CPU\_ZERO}(cpu\_set\_t *set)} - Inizializza l'insieme (vuoto). - \funcdecl{void \macro{CPU\_SET}(int cpu, cpu\_set\_t *set)} - Inserisce il processore \param{cpu} nell'insieme. +{\centering +\vspace{3pt} +\begin{funcbox}{ +\fhead{sched.h} +\fdecl{void \macro{CPU\_ZERO}(cpu\_set\_t *set)} +\fdesc{Inizializza l'insieme vuoto \param{set}.} +\fdecl{void \macro{CPU\_SET}(int cpu, cpu\_set\_t *set)} +\fdesc{Inserisce il processore \param{cpu} nell'insieme \param{set}.} +\fdecl{void \macro{CPU\_CLR}(int cpu, cpu\_set\_t *set)} +\fdesc{Rimuove il processore \param{cpu} nell'insieme \param{set}.} +\fdecl{int \macro{CPU\_ISSET}(int cpu, cpu\_set\_t *set)} +\fdesc{Controlla se il processore \param{cpu} è nell'insieme \param{set}.} +} +\end{funcbox}} + +% TODO trattare le altre - \funcdecl{void \macro{CPU\_CLR}(int cpu, cpu\_set\_t *set)} - Rimuove il processore \param{cpu} nell'insieme. - - \funcdecl{int \macro{CPU\_ISSET}(int cpu, cpu\_set\_t *set)} - Controlla se il processore \param{cpu} è nell'insieme. -\end{functions} - -Oltre a queste macro, simili alle analoghe usate per gli insiemi di file -descriptor (vedi sez.~\ref{sec:file_select}) è definita la costante -\const{CPU\_SETSIZE} che indica il numero massimo di processori che possono -far parte dell'insieme, e che costituisce un limite massimo al valore +Oltre a queste macro, simili alle analoghe usate per gli insiemi di +\textit{file descriptor} (vedi sez.~\ref{sec:file_select}) è definita la +costante \const{CPU\_SETSIZE} che indica il numero massimo di processori che +possono far parte dell'insieme, e che costituisce un limite massimo al valore dell'argomento \param{cpu}. In generale la maschera di affinità è preimpostata in modo che un processo possa essere eseguito su qualunque processore, se può comunque leggere il valore per un processo specifico usando la funzione \funcd{sched\_getaffinity}, il suo prototipo è: -\begin{prototype}{sched.h} - {int sched\_getaffinity (pid\_t pid, unsigned int cpusetsize, - const cpu\_set\_t *cpuset)} - Legge la maschera di affinità del processo \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: - \begin{errlist} - \item[\errcode{ESRCH}] il processo \param{pid} non esiste. - \item[\errcode{EFAULT}] il valore di \param{cpuset} non è un indirizzo - valido. - \end{errlist} } -\end{prototype} -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 -particolari. +\begin{funcproto}{ +\fhead{sched.h} +\fdecl{int sched\_getaffinity (pid\_t pid, size\_t cpusetsize, + cpu\_set\_t *mask)} +\fdesc{Legge la maschera di affinità di un processo.} +} +{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual +caso \var{errno} assumerà uno dei valori: +\begin{errlist} +\item[\errcode{ESRCH}] il processo \param{pid} non esiste. +\item[\errcode{EINVAL}] \param{cpusetsize} è più piccolo delle dimensioni + della maschera di affinità usata dal kernel. +\end{errlist} +ed inoltre anche \errval{EFAULT} nel suo significato generico.} +\end{funcproto} + +La funzione restituirà all'indirizzo specificato da \param{mask} il valore +della maschera di affinità del processo indicato dall'argomento \param{pid} +(al solito un valore nullo indica il processo corrente) così da poterla +riutilizzare per una successiva reimpostazione. L'argomento \param{cpusetsize} +indica la dimensione dell'argomento \param{mask} ed è in genere sufficiente +passare il valore \code{sizeof(cpu\_set\_t)}. È 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. +% TODO trattare i cpuset, che attiene anche a NUMA, e che possono essere usati +% per associare l'uso di gruppi di processori a gruppi di processi (vedi +% manpage omonima) +% TODO trattare getcpu, che attiene anche a NUMA + \itindend{scheduler} \itindend{CPU~affinity} @@ -3122,61 +3248,61 @@ stati introdotti diversi \textit{I/O scheduler} in grado di distribuire in maniera opportuna questa risorsa ai vari processi. Fino al kernel 2.6.17 era possibile soltanto differenziare le politiche generali di gestione, scegliendo di usare un diverso \textit{I/O scheduler}; a partire da questa versione, con -l'introduzione dello scheduler CFQ (\textit{Completely Fair Queuing}) è -divenuto possibile, qualora si usi questo scheduler, impostare anche delle -diverse priorità di accesso per i singoli processi.\footnote{al momento - (kernel 2.6.31), le priorità di I/O sono disponibili soltanto per questo - scheduler.} - -La scelta dello scheduler di I/O si può fare in maniera generica a livello di -avvio del kernel assegnando il nome dello stesso al parametro +l'introduzione dello \textit{scheduler} CFQ (\textit{Completely Fair Queuing}) +è divenuto possibile, qualora si usi questo \textit{scheduler}, impostare +anche delle diverse priorità di accesso per i singoli processi.\footnote{al + momento (kernel 2.6.31), le priorità di I/O sono disponibili soltanto per + questo \textit{scheduler}.} + +La scelta dello \textit{scheduler} di I/O si può fare in maniera generica a +livello di avvio del kernel assegnando il nome dello stesso al parametro \texttt{elevator}, mentre se ne può indicare uno per l'accesso al singolo disco scrivendo nel file \texttt{/sys/block/\textit{dev}/queue/scheduler} (dove \texttt{\textit{dev}} è il nome del dispositivo associato al disco); gli -scheduler disponibili sono mostrati dal contenuto dello stesso file che -riporta fra parentesi quadre quello attivo, il default in tutti i kernel +\textit{scheduler} disponibili sono mostrati dal contenuto dello stesso file +che riporta fra parentesi quadre quello attivo, il default in tutti i kernel recenti è proprio il \texttt{cfq},\footnote{nome con cui si indica appunto lo - scheduler \textit{Completely Fair Queuing}.} che supporta le priorità. Per i -dettagli sulle caratteristiche specifiche degli altri scheduler, la cui -discussione attiene a problematiche di ambito sistemistico, si consulti la -documentazione nella directory \texttt{Documentation/block/} dei sorgenti del -kernel. - -Una volta che si sia impostato lo scheduler CFQ ci sono due specifiche system -call, specifiche di Linux, che consentono di leggere ed impostare le priorità -di I/O.\footnote{se usate in corrispondenza ad uno scheduler diverso il loro - utilizzo non avrà alcun effetto.} Dato che non esiste una interfaccia -diretta nelle \acr{glibc} per queste due funzioni occorrerà invocarle tramite -la funzione \func{syscall} (come illustrato in -sez.~\ref{sec:proc_syscall}). Le due funzioni sono \funcd{ioprio\_get} ed -\funcd{ioprio\_set}; i rispettivi prototipi sono: -\begin{functions} - \headdecl{linux/ioprio.h} - \funcdecl{int ioprio\_get(int which, int who)} - \funcdecl{int ioprio\_set(int which, int who, int ioprio)} - - Rileva o imposta la priorità di I/O di un processo. - - \bodydesc{Le funzioni ritornano rispettivamente un intero positivo - (indicante la priorità) o 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}] non esiste il processo indicato. - \item[\errcode{EINVAL}] i valori di \param{which} e \param{who} non sono - validi. - \item[\errcode{EPERM}] non si hanno i privilegi per eseguire - l'impostazione (solo per \func{ioprio\_set}). - \end{errlist} } -\end{functions} + \textit{scheduler} CFQ.} che supporta le priorità. Per i dettagli sulle +caratteristiche specifiche degli altri \textit{scheduler}, la cui discussione +attiene a problematiche di ambito sistemistico, si consulti la documentazione +nella directory \texttt{Documentation/block/} dei sorgenti del kernel. + +Una volta che si sia impostato lo \textit{scheduler} CFQ ci sono due +specifiche system call, specifiche di Linux, che consentono di leggere ed +impostare le priorità di I/O.\footnote{se usate in corrispondenza ad uno + \textit{scheduler} diverso il loro utilizzo non avrà alcun effetto.} Dato +che non esiste una interfaccia diretta nelle \acr{glibc} per queste due +funzioni occorrerà invocarle tramite la funzione \func{syscall} (come +illustrato in sez.~\ref{sec:proc_syscall}). Le due funzioni sono +\funcd{ioprio\_get} ed \funcd{ioprio\_set}; i rispettivi prototipi sono: -Le funzioni leggono o impostano la priorità di I/O sulla base dell'indicazione +\begin{funcproto}{ +\fhead{linux/ioprio.h} +\fdecl{int ioprio\_get(int which, int who)} +\fdesc{Legge la priorità di I/O di un processo.} +\fdecl{int ioprio\_set(int which, int who, int ioprio)} +\fdesc{Imposta la priorità di I/O di un processo.} +} +{Le funzioni ritornano rispettivamente un intero positivo o 0 in caso di + successo e $-1$ per un errore, nel qual caso \var{errno} assumerà uno dei + valori: +\begin{errlist} +\item[\errcode{ESRCH}] non esiste un processo corrisponente alle indicazioni. +\item[\errcode{EINVAL}] i valori di \param{which} o di \param{iprio} non + sono validi. +\item[\errcode{EPERM}] non si hanno i privilegi per eseguire + l'impostazione (solo per \func{ioprio\_set}). +\end{errlist}} +\end{funcproto} + +Le funzioni leggono o impostano la priorità di I/O sulla base dell'indicazione dei due argomenti \param{which} e \param{who} che hanno lo stesso significato già visto per gli omonimi argomenti di \func{getpriority} e \func{setpriority}. Anche in questo caso si deve specificare il valore di \param{which} tramite le opportune costanti riportate in tab.~\ref{tab:ioprio_args} che consentono di indicare un singolo processo, i processi di un \textit{process group} (tratteremo questo argomento in -sez.~\ref{sec:sess_proc_group}) o tutti o processi di un utente. +sez.~\ref{sec:sess_proc_group}) o tutti i processi di un utente. \begin{table}[htb] \centering @@ -3200,18 +3326,19 @@ sez.~\ref{sec:sess_proc_group}) o tutti o processi di un utente. In caso di successo \func{ioprio\_get} restituisce un intero positivo che esprime il valore della priorità di I/O, questo valore è una maschera binaria -composta da due parti, una che esprime la \textsl{classe} di scheduling di I/O -del processo, l'altra che esprime, quando la classe di scheduling lo prevede, -la priorità del processo all'interno della classe stessa. Questo stesso -formato viene utilizzato per indicare il valore della priorità da impostare -con l'argomento \param{ioprio} di \func{ioprio\_set}. +composta da due parti, una che esprime la \textsl{classe} di +\textit{scheduling} di I/O del processo, l'altra che esprime, quando la classe +di \textit{scheduling} lo prevede, la priorità del processo all'interno della +classe stessa. Questo stesso formato viene utilizzato per indicare il valore +della priorità da impostare con l'argomento \param{ioprio} di +\func{ioprio\_set}. Per la gestione dei valori che esprimono le priorità di I/O sono state definite delle opportune macro di preprocessore, riportate in tab.~\ref{tab:IOsched_class_macro}. I valori delle priorità si ottengono o si impostano usando queste macro. Le prime due si usano con il valore restituito da \func{ioprio\_get} e per ottenere rispettivamente la classe di -scheduling\footnote{restituita dalla macro con i valori di +\textit{scheduling}\footnote{restituita dalla macro con i valori di tab.~\ref{tab:IOsched_class}.} e l'eventuale valore della priorità. La terza macro viene invece usata per creare un valore di priorità da usare come argomento di \func{ioprio\_set} per eseguire una impostazione. @@ -3242,20 +3369,11 @@ argomento di \func{ioprio\_set} per eseguire una impostazione. \label{tab:IOsched_class_macro} \end{table} -Le classi di scheduling previste dallo scheduler CFQ sono tre, e ricalcano tre -diverse modalità di distribuzione delle risorse analoghe a quelle già adottate -anche nel funzionamento dello scheduler del processore. Ciascuna di esse è -identificata tramite una opportuna costante, secondo quanto riportato in -tab.~\ref{tab:IOsched_class}. - -La classe di priorità più bassa è \const{IOPRIO\_CLASS\_IDLE}; i processi in -questa classe riescono ad accedere a disco soltanto quando nessun altro -processo richiede l'accesso. Occorre pertanto usarla con molta attenzione, -perché un processo in questa classe può venire completamente bloccato quando -ci sono altri processi in una qualunque delle altre due classi che stanno -accedendo al disco. Quando si usa questa classe non ha senso indicare un -valore di priorità, dato che in questo caso non esiste nessuna gerarchia e la -priorità è identica, la minima possibile, per tutti i processi. +Le classi di \textit{scheduling} previste dallo \textit{scheduler} CFQ sono +tre, e ricalcano tre diverse modalità di distribuzione delle risorse analoghe +a quelle già adottate anche nel funzionamento dello \textit{scheduler} del +processore. Ciascuna di esse è identificata tramite una opportuna costante, +secondo quanto riportato in tab.~\ref{tab:IOsched_class}. \begin{table}[htb] \centering @@ -3265,15 +3383,24 @@ priorità è identica, la minima possibile, per tutti i processi. \textbf{Classe} & \textbf{Significato} \\ \hline \hline - \const{IOPRIO\_CLASS\_RT} & Scheduling di I/O \textit{real time}.\\ - \const{IOPRIO\_CLASS\_BE} & Scheduling di I/O ordinario.\\ - \const{IOPRIO\_CLASS\_IDLE}& Scheduling di I/O di priorità minima.\\ + \const{IOPRIO\_CLASS\_RT} & \textit{Scheduling} di I/O \textit{real-time}.\\ + \const{IOPRIO\_CLASS\_BE} & \textit{Scheduling} di I/O ordinario.\\ + \const{IOPRIO\_CLASS\_IDLE}& \textit{Scheduling} di I/O di priorità minima.\\ \hline \end{tabular} - \caption{Costanti che identificano le classi di scheduling di I/O.} + \caption{Costanti che identificano le classi di \textit{scheduling} di I/O.} \label{tab:IOsched_class} \end{table} +La classe di priorità più bassa è \const{IOPRIO\_CLASS\_IDLE}; i processi in +questa classe riescono ad accedere a disco soltanto quando nessun altro +processo richiede l'accesso. Occorre pertanto usarla con molta attenzione, +perché un processo in questa classe può venire completamente bloccato quando +ci sono altri processi in una qualunque delle altre due classi che stanno +accedendo al disco. Quando si usa questa classe non ha senso indicare un +valore di priorità, dato che in questo caso non esiste nessuna gerarchia e la +priorità è identica, la minima possibile, per tutti i processi. + La seconda classe di priorità di I/O è \const{IOPRIO\_CLASS\_BE} (il nome sta per \textit{best-effort}) che è quella usata ordinariamente da tutti processi. In questo caso esistono priorità diverse che consentono di @@ -3303,9 +3430,9 @@ utente ordinario può modificare con \func{ioprio\_set} soltanto le priorità dei processi che gli appartengono,\footnote{per la modifica delle priorità di altri processi occorrono privilegi amministrativi, ed in particolare la capacità \const{CAP\_SYS\_NICE} (vedi sez.~\ref{sec:proc_capabilities}).} -cioè quelli il cui user-ID reale corrisponde all'user-ID reale o effettivo del -chiamante. Data la possibilità di ottenere un blocco totale del sistema, solo -l'amministratore\footnote{o un processo con la capacità +cioè quelli il cui \acr{uid} reale corrisponde all'\acr{uid} reale o effettivo +del chiamante. Data la possibilità di ottenere un blocco totale del sistema, +solo l'amministratore\footnote{o un processo con la capacità \const{CAP\_SYS\_ADMIN} (vedi sez.~\ref{sec:proc_capabilities}).} può impostare un processo ad una priorità di I/O nella classe \const{IOPRIO\_CLASS\_RT}, lo stesso privilegio era richiesto anche per la @@ -3316,7 +3443,8 @@ rimosso a partire dal kernel 2.6.25. %TODO verificare http://lwn.net/Articles/355987/ %TODO trattare le funzionalità per il NUMA -% vedi man numa e le pagine di manuale relative +% vedi man numa e, mbind, get_mempolicy, set_mempolicy, +% le pagine di manuale relative % vedere anche dove metterle... @@ -3332,159 +3460,6 @@ spesso presuppongono la conoscenza di altri argomenti trattati nel seguito della guida, si può saltare questa sezione in una prima lettura, tornando su di essa in un secondo tempo. -\subsection{La \textit{system call} \func{clone}} -\label{sec:process_clone} - -La funzione tradizionale con cui creare un nuovo processo in un sistema -Unix-like, come illustrato in sez.~\ref{sec:proc_fork}, è \func{fork}, ma con -l'introduzione del supporto del kernel per i \textit{thread} (vedi -cap.~\ref{cha:threads}), si è avuta la necessità di una interfaccia che -consentisse un maggiore controllo sulla modalità con cui vengono creati nuovi -processi, che poi è stata utilizzata anche per fornire supporto per le -tecnologie di virtualizzazione dei processi (i cosiddetti \textit{container}). - -Per questo l'interfaccia per la creazione di un nuovo processo è stata -delegata ad una nuova \textit{system call}, \func{sys\_clone}, che consente di -reimplementare anche la tradizionale \func{fork}. In realtà in questo caso più -che di nuovi processi si può parlare della creazioni di nuovi -``\textit{task}'' del kernel che possono assumere la veste sia di un processo -classico come quelli trattati finora, che di un \textit{thread}, come quelli -che vedremo in sez.~\ref{sec:linux_thread}, in cui la memoria viene condivisa -fra il processo chiamante ed il nuovo processo creato. Per evitare confusione -fra \textit{thread} e processi ordinari, abbiamo deciso di usare la -nomenclatura \textit{task} per indicare la unità di esecuzione generica messa -a disposizione del kernel che \texttt{sys\_clone} permette di creare. - -Oltre a questo la funzione consente, ad uso delle nuove funzionalità di -virtualizzazione dei processi, di creare nuovi \textit{namespace} per una -serie di proprietà generali dei processi (come l'elenco dei PID, l'albero dei -file, dei \textit{mount point}, della rete, ecc.), che consentono di creare -gruppi di processi che vivono in una sorta di spazio separato dagli altri, che -costituisce poi quello che viene chiamato un \textit{container}. - -La \textit{system call} richiede soltanto due argomenti: il -primo, \param{flags}, consente di controllare le modalità di creazione del -nuovo \textit{task}, il secondo, \param{child\_stack}, imposta l'indirizzo -dello \itindex{stack} \textit{stack} per il nuovo \textit{task}, e deve essere -indicato quando si intende creare un \textit{thread}. L'esecuzione del -programma creato da \func{sys\_clone} riprende, come per \func{fork}, da -dopo l'esecuzione della stessa. - -La necessità di avere uno \itindex{stack} \textit{stack} alternativo c'è solo -quando si intende creare un \textit{thread}, in tal caso infatti il nuovo -\textit{task} vede esattamente la stessa memoria del \textit{task} -``\textsl{padre}'',\footnote{in questo caso per padre si intende semplicemente - il \textit{task} che ha eseguito \func{sys\_clone} rispetto al \textit{task} - da essa creato, senza nessuna delle implicazioni che il concetto ha per i - processi.} e nella sua esecuzione alla prima chiamata di una funzione -andrebbe a scrivere sullo \textit{stack} usato anche dal padre (si ricordi -quanto visto in sez.~\ref{sec:proc_mem_layout} riguardo all'uso dello -\textit{stack}). - -Per evitare di doversi garantire contro la evidente possibilità di -\itindex{race~condition} \textit{race condition} che questa situazione -comporta (vedi sez.~\ref{sec:proc_race_cond} per una spiegazione della -problematica) è necessario che il chiamante allochi preventivamente un'area di -memoria. In genere lo si fa con una \func{malloc} che allochi un buffer che -la funzione imposterà come \textit{stack} del nuovo processo, avendo -ovviamente cura di non utilizzarlo direttamente nel processo chiamante. In -questo modo i due \textit{task} avranno degli \textit{stack} indipendenti e -non si dovranno affrontare problematiche di \itindex{race~condition} -\textit{race condition}. Si tenga presente inoltre che in molte architetture -di processore lo \textit{stack} cresce verso il basso, pertanto in tal caso -non si dovrà specificare per \param{child\_stack} il puntatore restituito da -\func{malloc}, ma un puntatore alla fine del buffer da essa allocato. - -Dato che tutto ciò è necessario solo per i \textit{thread} che condividono la -memoria, la \textit{system call}, a differenza della funzione di libreria che -vedremo a breve, consente anche di passare per \param{child\_stack} il valore -\val{NULL}, che non imposta un nuovo \textit{stack}. Se infatti si crea un -processo, questo ottiene un suo nuovo spazio degli indirizzi,\footnote{è - sottinteso cioè che non si stia usando il flag \const{CLONE\_VM}.} ed in -questo caso si applica la semantica del \itindex{copy~on~write} \textit{copy - on write} illustrata in sez.~\ref{sec:proc_fork}, per cui le pagine dello -\textit{stack} verranno automaticamente copiate come le altre e il nuovo -processo avrà un suo \textit{stack} totalmente indipendente da quello del -padre. - -Dato che l'uso principale della nuova \textit{system call} è quello relativo -alla creazione dei \textit{thread}, le \acr{glibc} definiscono una funzione di -libreria con una sintassi diversa, orientata a questo scopo, e la -\textit{system call} resta accessibile solo se invocata esplicitamente come -visto in sez.~\ref{sec:proc_syscall}.\footnote{ed inoltre per questa - \textit{system call} non è disponibile la chiamata veloce con - \texttt{vsyscall}.} La funzione di libreria si chiama semplicemente -\funcd{clone} ed il suo prototipo è: -\begin{functions} - \headdecl{sys/sched.h} - - \funcdecl{int clone(int (*fn)(void *), void *child\_stack, int - flags, void *arg, ... \\ - /* pid\_t *ptid, struct user\_desc *tls, pid\_t *ctid */)} - - Crea un nuovo processo o \textit{thread} eseguendo la funzione \param{fn}. - - \bodydesc{La funzione ritorna al chiamante il \textit{Thread ID} assegnato - al nuovo processo in caso di successo e $-1$ in caso di errore, nel qual - caso \var{errno} può assumere i valori: - \begin{errlist} - \item[\errcode{EAGAIN}] sono già in esecuzione troppi processi. - \item[\errcode{EINVAL}] si è usata una combinazione non valida di flag o - un valore nullo per \param{child\_stack}. - \item[\errcode{ENOMEM}] non c'è memoria sufficiente per creare una nuova - \struct{task\_struct} o per copiare le parti del contesto del chiamante - necessarie al nuovo \textit{task}. - \item[\errcode{EPERM}] non si hanno i privilegi di amministratore - richiesti dai flag indicati. - \end{errlist} - } -\end{functions} - -La funzione prende come primo argomento il puntatore alla funzione che verrà -messa in esecuzione nel nuovo processo, che può avere un unico argomento di -tipo puntatore a \ctyp{void}, il cui valore viene passato dal terzo -argomento \param{arg}; per quanto il precedente prototipo possa intimidire -nella sua espressione, in realtà l'uso è molto semplice basterà definire una -qualunque funzione \param{fn} del tipo indicato, e \code{fn(arg)} sarà -eseguita in un nuovo processo. - -Il nuovo processo resterà in esecuzione fintanto che la funzione \param{fn} -non ritorna, o esegue \func{exit} o viene terminata da un segnale. Il valore -di ritorno della funzione (o quello specificato con \func{exit}) verrà -utilizzato come stato di uscita della funzione. - -I tre argomenti \param{ptid}, \param{tls} e \param{ctid} sono opzionali e sono -presenti solo a partire dal kernel 2.6. - -Il comportamento di \func{clone}, che si riflette sulle caratteristiche del -nuovo processo da essa creato, è controllato dall'argomento \param{flags}, - -\begin{basedescript}{\desclabelstyle{\pushlabel}} - -\item[\const{CLONE\_CHILD\_CLEARTID}] -\item[\const{CLONE\_CHILD\_SETTID}] -\item[\const{CLONE\_FILES}] -\item[\const{CLONE\_FS}] -\item[\const{CLONE\_IO}] -\item[\const{CLONE\_NEWIPC}] -\item[\const{CLONE\_NEWNET}] -\item[\const{CLONE\_NEWNS}] -\item[\const{CLONE\_NEWPID}] -\item[\const{CLONE\_NEWUTS}] -\item[\const{CLONE\_PARENT}] -\item[\const{CLONE\_PARENT\_SETTID}] -\item[\const{CLONE\_PID}] -\item[\const{CLONE\_PTRACE}] -\item[\const{CLONE\_SETTLS}] -\item[\const{CLONE\_SIGHAND}] -\item[\const{CLONE\_STOPPED}] -\item[\const{CLONE\_SYSVSEM}] -\item[\const{CLONE\_THREAD}] -\item[\const{CLONE\_UNTRACED}] -\item[\const{CLONE\_VFORK}] -\item[\const{CLONE\_VM}] -\end{basedescript} - \subsection{La funzione \func{prctl}} \label{sec:process_prctl} @@ -3497,19 +3472,18 @@ fornisce una interfaccia generica per tutte le operazioni specialistiche. La funzione è \funcd{prctl} ed il suo prototipo è:\footnote{la funzione non è standardizzata ed è specifica di Linux, anche se ne esiste una analoga in IRIX; è stata introdotta con il kernel 2.1.57.} -\begin{functions} - \headdecl{sys/prctl.h} - \funcdecl{int prctl(int option, unsigned long arg2, unsigned long arg3, +\begin{funcproto}{ +\fhead{sys/prctl.h} +\fdecl{int prctl(int option, unsigned long arg2, unsigned long arg3, unsigned long arg4, unsigned long arg5)} - - Esegue una operazione speciale sul processo corrente. - - \bodydesc{La funzione ritorna 0 o un valore positivo dipendente - dall'operazione in caso di successo e $-1$ in caso di errore, nel qual - caso \var{errno} assumerà valori diversi a seconda del tipo di operazione - richiesta (in genere \errval{EINVAL} o \errval{EPERM}). } -\end{functions} +\fdesc{Esegue una operazione speciale sul processo corrente.} +} +{La funzione ritorna $0$ o un valore positivo dipendente dall'operazione in + caso di successo e $-1$ per un errore, nel qual caso \var{errno} assumerà + valori diversi a seconda del tipo di operazione richiesta (in genere + \errval{EINVAL} o \errval{EPERM}).} +\end{funcproto} La funzione ritorna un valore nullo o positivo in caso di successo e $-1$ in caso di errore; il significato degli argomenti della funzione successivi al @@ -3761,6 +3735,156 @@ predefinite del seguente elenco, che illustra quelle disponibili al momento: \end{basedescript} +\subsection{La \textit{system call} \func{clone}} +\label{sec:process_clone} + +La funzione tradizionale con cui creare un nuovo processo in un sistema +Unix-like, come illustrato in sez.~\ref{sec:proc_fork}, è \func{fork}, ma con +l'introduzione del supporto del kernel per i \textit{thread} (vedi +cap.~\ref{cha:threads}), si è avuta la necessità di una interfaccia che +consentisse un maggiore controllo sulla modalità con cui vengono creati nuovi +processi, che poi è stata utilizzata anche per fornire supporto per le +tecnologie di virtualizzazione dei processi (i cosiddetti \textit{container}). + +Per questo l'interfaccia per la creazione di un nuovo processo è stata +delegata ad una nuova \textit{system call}, \func{sys\_clone}, che consente di +reimplementare anche la tradizionale \func{fork}. In realtà in questo caso più +che di nuovi processi si può parlare della creazioni di nuovi +``\textit{task}'' del kernel che possono assumere la veste sia di un processo +classico come quelli trattati finora, che di un \textit{thread}, come quelli +che vedremo in sez.~\ref{sec:linux_thread}, in cui la memoria viene condivisa +fra il processo chiamante ed il nuovo processo creato. Per evitare confusione +fra \textit{thread} e processi ordinari, abbiamo deciso di usare la +nomenclatura \textit{task} per indicare la unità di esecuzione generica messa +a disposizione del kernel che \texttt{sys\_clone} permette di creare. + +Oltre a questo la funzione consente, ad uso delle nuove funzionalità di +virtualizzazione dei processi, di creare nuovi \textit{namespace} per una +serie di proprietà generali dei processi (come l'elenco dei PID, l'albero dei +file, dei \textit{mount point}, della rete, ecc.), che consentono di creare +gruppi di processi che vivono in una sorta di spazio separato dagli altri, che +costituisce poi quello che viene chiamato un \textit{container}. + +La \textit{system call} richiede soltanto due argomenti: il +primo, \param{flags}, consente di controllare le modalità di creazione del +nuovo \textit{task}, il secondo, \param{child\_stack}, imposta l'indirizzo +dello \itindex{stack} \textit{stack} per il nuovo \textit{task}, e deve essere +indicato quando si intende creare un \textit{thread}. L'esecuzione del +programma creato da \func{sys\_clone} riprende, come per \func{fork}, da +dopo l'esecuzione della stessa. + +La necessità di avere uno \itindex{stack} \textit{stack} alternativo c'è solo +quando si intende creare un \textit{thread}, in tal caso infatti il nuovo +\textit{task} vede esattamente la stessa memoria del \textit{task} +``\textsl{padre}'',\footnote{in questo caso per padre si intende semplicemente + il \textit{task} che ha eseguito \func{sys\_clone} rispetto al \textit{task} + da essa creato, senza nessuna delle implicazioni che il concetto ha per i + processi.} e nella sua esecuzione alla prima chiamata di una funzione +andrebbe a scrivere sullo \textit{stack} usato anche dal padre (si ricordi +quanto visto in sez.~\ref{sec:proc_mem_layout} riguardo all'uso dello +\textit{stack}). + +Per evitare di doversi garantire contro la evidente possibilità di +\itindex{race~condition} \textit{race condition} che questa situazione +comporta (vedi sez.~\ref{sec:proc_race_cond} per una spiegazione della +problematica) è necessario che il chiamante allochi preventivamente un'area di +memoria. In genere lo si fa con una \func{malloc} che allochi un buffer che +la funzione imposterà come \textit{stack} del nuovo processo, avendo +ovviamente cura di non utilizzarlo direttamente nel processo chiamante. + +In questo modo i due \textit{task} avranno degli \textit{stack} indipendenti e +non si dovranno affrontare problematiche di \itindex{race~condition} +\textit{race condition}. Si tenga presente inoltre che in molte architetture +di processore lo \textit{stack} cresce verso il basso, pertanto in tal caso +non si dovrà specificare per \param{child\_stack} il puntatore restituito da +\func{malloc}, ma un puntatore alla fine del buffer da essa allocato. + +Dato che tutto ciò è necessario solo per i \textit{thread} che condividono la +memoria, la \textit{system call}, a differenza della funzione di libreria che +vedremo a breve, consente anche di passare per \param{child\_stack} il valore +\val{NULL}, che non imposta un nuovo \textit{stack}. Se infatti si crea un +processo, questo ottiene un suo nuovo spazio degli indirizzi,\footnote{è + sottinteso cioè che non si stia usando il flag \const{CLONE\_VM} che vedremo + a breve.} ed in questo caso si applica la semantica del +\itindex{copy~on~write} \textit{copy on write} illustrata in +sez.~\ref{sec:proc_fork}, per cui le pagine dello \textit{stack} verranno +automaticamente copiate come le altre e il nuovo processo avrà un suo +\textit{stack} totalmente indipendente da quello del padre. + +Dato che l'uso principale della nuova \textit{system call} è quello relativo +alla creazione dei \textit{thread}, le \acr{glibc} definiscono una funzione di +libreria con una sintassi diversa, orientata a questo scopo, e la +\textit{system call} resta accessibile solo se invocata esplicitamente come +visto in sez.~\ref{sec:proc_syscall}.\footnote{ed inoltre per questa + \textit{system call} non è disponibile la chiamata veloce con + \texttt{vsyscall}.} La funzione di libreria si chiama semplicemente +\funcd{clone} ed il suo prototipo è: + +\begin{funcproto}{ +\fhead{sched.h} +\fdecl{int clone(int (*fn)(void *), void *child\_stack, int flags, void *arg, ... /* pid\_t *ptid, struct user\_desc *tls, pid\_t *ctid */)} +\fdesc{Crea un nuovo processo o \textit{thread}.} +} +{La funzione ritorna il \textit{Thread ID} assegnato al nuovo processo in caso + di successo e $-1$ per un errore, nel qual caso \var{errno} assumerà uno dei + valori: +\begin{errlist} + \item[\errcode{EAGAIN}] sono già in esecuzione troppi processi. + \item[\errcode{EINVAL}] si è usata una combinazione non valida di flag o + un valore nullo per \param{child\_stack}. + \item[\errcode{ENOMEM}] non c'è memoria sufficiente per creare una nuova + \struct{task\_struct} o per copiare le parti del contesto del chiamante + necessarie al nuovo \textit{task}. + \item[\errcode{EPERM}] non si hanno i privilegi di amministratore + richiesti dai flag indicati. +\end{errlist}} +\end{funcproto} + +La funzione prende come primo argomento \param{fn} il puntatore alla funzione +che verrà messa in esecuzione nel nuovo processo, che può avere un unico +argomento di tipo puntatore a \ctyp{void}, il cui valore viene passato dal +terzo argomento \param{arg}. Per quanto il precedente prototipo possa +intimidire nella sua espressione, in realtà l'uso è molto semplice basterà +definire una qualunque funzione \param{fn} che restitisce un intero ed ha come +argomento un puntatore a \ctyp{vois}, e \code{fn(arg)} sarà eseguita in un +nuovo processo. + +Il nuovo processo resterà in esecuzione fintanto che la funzione \param{fn} +non ritorna, o esegue \func{exit} o viene terminata da un segnale. Il valore +di ritorno della funzione (o quello specificato con \func{exit}) verrà +utilizzato come stato di uscita della funzione. I tre +argomenti \param{ptid}, \param{tls} e \param{ctid} sono opzionali e sono +presenti solo a partire dal kernel 2.6 ed usati principalmente per le funzioni +di gestione dei \textit{thread} presenti nella \acr{glibc}. + +Il comportamento di \func{clone}, che si riflette sulle caratteristiche del +nuovo processo da essa creato, è controllato dall'argomento \param{flags}, + +\begin{basedescript}{\desclabelstyle{\pushlabel}} + +\item[\const{CLONE\_CHILD\_CLEARTID}] +\item[\const{CLONE\_CHILD\_SETTID}] +\item[\const{CLONE\_FILES}] +\item[\const{CLONE\_FS}] +\item[\const{CLONE\_IO}] +\item[\const{CLONE\_NEWIPC}] +\item[\const{CLONE\_NEWNET}] +\item[\const{CLONE\_NEWNS}] +\item[\const{CLONE\_NEWPID}] +\item[\const{CLONE\_NEWUTS}] +\item[\const{CLONE\_PARENT}] +\item[\const{CLONE\_PARENT\_SETTID}] +\item[\const{CLONE\_PID}] +\item[\const{CLONE\_PTRACE}] +\item[\const{CLONE\_SETTLS}] +\item[\const{CLONE\_SIGHAND}] +\item[\const{CLONE\_STOPPED}] +\item[\const{CLONE\_SYSVSEM}] +\item[\const{CLONE\_THREAD}] +\item[\const{CLONE\_UNTRACED}] +\item[\const{CLONE\_VFORK}] +\item[\const{CLONE\_VM}] +\end{basedescript} \subsection{La funzione \func{ptrace}} @@ -3771,6 +3895,16 @@ Da fare % TODO: trattare PTRACE_SEIZE, aggiunta con il kernel 3.1 +\subsection{La gestione delle operazioni in virgola mobile} +\label{sec:process_fenv} + +Da fare. + +% TODO eccezioni ed arrotondamenti per la matematica in virgola mobile +% consultare la manpage di fenv, math_error, fpclassify, matherr, isgreater, +% isnan, nan, INFINITY + + \subsection{L'accesso alle porte di I/O} \label{sec:process_io_port} @@ -3974,9 +4108,9 @@ aggiungendo il suffisso \code{\_r} al nome della versione normale. % 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 preemptive cache runnable Stopped -% LocalWords: Uninterrutible SIGSTOP soft slice nice niceness counter which SC -% LocalWords: getpriority who setpriority RTLinux RTAI Adeos fault FIFO First +% LocalWords: pag ssize length proc capgetp preemptive cache runnable +% LocalWords: SIGSTOP soft slice nice niceness counter which SC +% LocalWords: getpriority who setpriority RTLinux RTAI Adeos fault FIFO % 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 @@ -3991,7 +4125,7 @@ aggiungendo il suffisso \code{\_r} al nome della versione normale. % LocalWords: waitid NOCLDSTOP ENOCHLD WIFCONTINUED ifdef endif idtype siginfo % LocalWords: infop ALL WEXITED WSTOPPED WNOWAIT signo CLD EXITED KILLED page % LocalWords: CONTINUED sources forking Spawned successfully executing exiting -% LocalWords: next cat for COMMAND pts bash defunct TRAPPED DUMPED Killable PR +% LocalWords: next cat for COMMAND pts bash defunct TRAPPED DUMPED PR % LocalWords: SIGKILL static RLIMIT preemption PREEMPT VOLUNTARY IDLE RTPRIO % LocalWords: completely fair compat uniform CFQ queuing elevator dev cfq RT % LocalWords: documentation block syscall ioprio IPRIO CLASS class best effort @@ -4003,7 +4137,8 @@ aggiungendo il suffisso \code{\_r} al nome della versione normale. % LocalWords: secure computing sigreturn TIMING STATISTICAL TSC MCE conditions % LocalWords: timestamp Stamp SIGSEGV UNALIGN SIGBUS MCEERR AO failure early % LocalWords: namespace vsyscall SETTID FILES NEWIPC NEWNET NEWNS NEWPID ptid -% LocalWords: NEWUTS SETTLS SIGHAND SYSVSEM UNTRACED tls ctid CLEARTID +% LocalWords: NEWUTS SETTLS SIGHAND SYSVSEM UNTRACED tls ctid CLEARTID panic +% LocalWords: loader EISDIR SIGTRAP uninterrutible killable %%% Local Variables: %%% mode: latex diff --git a/session.tex b/session.tex index a1bbe4e..eba2f1c 100644 --- a/session.tex +++ b/session.tex @@ -601,8 +601,8 @@ provvede a costruire gli opportuni valori per le variabili di ambiente, come \texttt{HOME}, \texttt{SHELL}, ecc. Infine attraverso l'uso di \func{setuid}, \func{setgid} e \func{initgroups} verrà cambiata l'identità del proprietario del processo, infatti, come spiegato in sez.~\ref{sec:proc_setuid}, avendo -invocato tali funzioni con i privilegi di amministratore, tutti gli user-ID ed -i group-ID (reali, effettivi e salvati) saranno impostati a quelli +invocato tali funzioni con i privilegi di amministratore, tutti gli \acr{uid} +ed i \acr{gid} (reali, effettivi e salvati) saranno impostati a quelli dell'utente. A questo punto \cmd{login} provvederà (fatte salve eventuali altre azioni diff --git a/signal.tex b/signal.tex index 302b5e3..0d0e5ee 100644 --- a/signal.tex +++ b/signal.tex @@ -1065,9 +1065,9 @@ Una seconda funzione che può essere definita in termini di \func{kill} è \end{table} Solo l'amministratore può inviare un segnale ad un processo qualunque, in -tutti gli altri casi l'user-ID reale o l'user-ID effettivo del processo -chiamante devono corrispondere all'user-ID reale o all'user-ID salvato della -destinazione. Fa eccezione il caso in cui il segnale inviato sia +tutti gli altri casi l'\acr{uid} reale o l'\acr{uid} effettivo del processo +chiamante devono corrispondere all'\acr{uid} reale o all'\acr{uid} salvato +della destinazione. Fa eccezione il caso in cui il segnale inviato sia \signal{SIGCONT}, nel quale occorre che entrambi i processi appartengano alla stessa sessione. Inoltre, dato il ruolo fondamentale che riveste nel sistema (si ricordi quanto visto in sez.~\ref{sec:sig_termination}), non è possibile @@ -2423,7 +2423,7 @@ fig.~\ref{fig:sig_siginfo_t}, nella trattazione dei gestori in forma estesa. In particolare i campi utilizzati dai segnali \textit{real-time} sono \var{si\_pid} e \var{si\_uid} in cui vengono memorizzati rispettivamente il -\acr{pid} e l'user-ID effettivo del processo che ha inviato il segnale, mentre +\acr{pid} e l'\acr{uid} effettivo del processo che ha inviato il segnale, mentre per la restituzione dei dati viene usato il campo \var{si\_value}. \begin{figure}[!htb] diff --git a/socket.tex b/socket.tex index 88029d6..058c4e4 100644 --- a/socket.tex +++ b/socket.tex @@ -249,7 +249,7 @@ tab.~\ref{tab:net_pf_names}.\footnote{l'elenco indica tutti i protocolli Si tenga presente che non tutte le famiglie di protocolli sono utilizzabili dall'utente generico, ad esempio in generale tutti i socket di tipo \const{SOCK\_RAW} possono essere creati solo da processi che hanno i privilegi -di amministratore (cioè con user-ID effettivo uguale a zero) o dotati della +di amministratore (cioè con \acr{uid} effettivo uguale a zero) o dotati della \itindex{capabilities} \textit{capability} \const{CAP\_NET\_RAW}. @@ -474,7 +474,7 @@ Il membro \var{sin\_family} deve essere sempre impostato a \const{AF\_INET}, altrimenti si avrà un errore di \errcode{EINVAL}; il membro \var{sin\_port} specifica il \textsl{numero di porta}. I numeri di porta sotto il 1024 sono chiamati \textsl{riservati} in quanto utilizzati da servizi standard e -soltanto processi con i privilegi di amministratore (con user-ID effettivo +soltanto processi con i privilegi di amministratore (con \acr{uid} effettivo uguale a zero) o con la \itindex{capabilities} \textit{capability} \const{CAP\_NET\_BIND\_SERVICE} possono usare la funzione \func{bind} (che vedremo in sez.~\ref{sec:TCP_func_bind}) su queste porte. @@ -655,7 +655,7 @@ simboliche definite nel file \file{linux/if\_ether.h}. Se si usa il valore speciale \const{ETH\_P\_ALL} passeranno sul \textit{packet socket} tutti i pacchetti, qualunque sia il loro protocollo di collegamento. Ovviamente l'uso di questi socket è una operazione privilegiata e può essere effettuati solo da -un processo con i privilegi di amministratore (user-ID effettivo nullo) o con +un processo con i privilegi di amministratore (\acr{uid} effettivo nullo) o con la \itindex{capabilities} \textit{capability} \const{CAP\_NET\_RAW}. Una volta aperto un \textit{packet socket}, tutti i pacchetti del protocollo -- 2.30.2