X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=prochand.tex;h=b2b2b0b213489455625f2529c24675aa0826c3d5;hp=569e06bed7c94ab4311b48e8b6ca85bcd26870a1;hb=6f8e0ca42d3d0b97b5e5747798a1eaffb44e8521;hpb=85a775d4f7a3dae1e72e449f2c05f03170a3295d diff --git a/prochand.tex b/prochand.tex index 569e06b..b2b2b0b 100644 --- a/prochand.tex +++ b/prochand.tex @@ -126,13 +126,13 @@ struttura, alla cui base c' processi. Il kernel mantiene una tabella dei processi attivi, la cosiddetta -\textit{process table}; per ciascun processo viene mantenuta una voce, -costituita da una struttura \struct{task\_struct}, nella tabella dei processi -che contiene tutte le informazioni rilevanti per quel processo. Tutte le -strutture usate a questo scopo sono dichiarate nell'header file -\file{linux/sched.h}, ed uno schema semplificato, che riporta la struttura -delle principali informazioni contenute nella \struct{task\_struct} (che in -seguito incontreremo a più riprese), è mostrato in +\itindex{process~table} \textit{process table}; per ciascun processo viene +mantenuta una voce, costituita da una struttura \struct{task\_struct}, nella +tabella dei processi che contiene tutte le informazioni rilevanti per quel +processo. Tutte le strutture usate a questo scopo sono dichiarate nell'header +file \file{linux/sched.h}, ed uno schema semplificato, che riporta la +struttura delle principali informazioni contenute nella \struct{task\_struct} +(che in seguito incontreremo a più riprese), è mostrato in fig.~\ref{fig:proc_task_struct}. \begin{figure}[htb] @@ -146,16 +146,18 @@ fig.~\ref{fig:proc_task_struct}. Come accennato in sez.~\ref{sec:intro_unix_struct} è lo \textit{scheduler}\itindex{scheduler} che decide quale processo mettere in esecuzione; esso viene eseguito ad ogni system call ed ad ogni -interrupt,\footnote{più in una serie di altre occasioni. NDT completare questa - parte.} (ma può essere anche attivato esplicitamente). Il timer di sistema -provvede comunque a che esso sia invocato periodicamente, generando un -interrupt periodico secondo la frequenza specificata dalla costante -\const{HZ}, definita in \file{asm/param.h}, ed il cui valore è espresso in -Hertz.\footnote{Il valore usuale di questa costante è 100, per tutte le - architetture eccetto l'alpha, per la quale è 1000. Occorre fare attenzione a - non confondere questo valore con quello dei clock tick (vedi +interrupt,\footnote{più in una serie di altre occasioni.} +% TODO completare questa parte. +(ma può essere anche attivato esplicitamente). Il timer di sistema provvede +comunque a che esso sia invocato periodicamente, generando un interrupt +periodico secondo la frequenza specificata dalla costante \const{HZ}, definita +in \file{asm/param.h}, ed il cui valore è espresso in Hertz.\footnote{Fino al + kernel 2.4 l valore usuale di questa costante era 100, per tutte le + architetture eccetto l'alpha, per la quale era 1000. Occorre fare attenzione + a non confondere questo valore con quello dei clock tick (vedi sez.~\ref{sec:sys_unix_time}).} -%Si ha cioè un interrupt dal timer ogni centesimo di secondo. +% TODO verificare gli ultimi cambiamenti del 2.6 +% Si ha cioè un interrupt dal timer ogni centesimo di secondo. Ogni volta che viene eseguito, lo \textit{scheduler}\itindex{scheduler} effettua il calcolo delle priorità dei vari processi attivi (torneremo su @@ -317,22 +319,22 @@ prototipo della funzione Dopo il successo dell'esecuzione di una \func{fork} sia il processo padre che il processo figlio continuano ad essere eseguiti normalmente a partire dall'istruzione successiva alla \func{fork}; il processo figlio è però una -copia del padre, e riceve una copia dei segmenti di testo, stack e dati (vedi -sez.~\ref{sec:proc_mem_layout}), ed esegue esattamente lo stesso codice del -padre. Si tenga presente però che la memoria è copiata, non condivisa, -pertanto padre e figlio vedono variabili diverse. - -Per quanto riguarda la gestione della memoria, in generale il segmento di -testo, che è identico per i due processi, è condiviso e tenuto in read-only -per il padre e per i figli. Per gli altri segmenti Linux utilizza la tecnica -del \textit{copy on write}\itindex{copy~on~write}; questa tecnica -comporta che una pagina di memoria viene effettivamente copiata per il nuovo -processo solo quando ci viene effettuata sopra una scrittura (e si ha quindi -una reale differenza fra padre e figlio). In questo modo si rende molto più -efficiente il meccanismo della creazione di un nuovo processo, non essendo più -necessaria la copia di tutto lo spazio degli indirizzi virtuali del padre, ma -solo delle pagine di memoria che sono state modificate, e solo al momento -della modifica stessa. +copia del padre, e riceve una copia dei segmenti di testo, \itindex{stack} +stack e dati (vedi sez.~\ref{sec:proc_mem_layout}), ed esegue esattamente lo +stesso codice del padre. Si tenga presente però che la memoria è copiata, non +condivisa, pertanto padre e figlio vedono variabili diverse. + +Per quanto riguarda la gestione della memoria, in generale +il\index{segmento!testo} segmento di testo, che è identico per i due processi, +è condiviso e tenuto in read-only per il padre e per i figli. Per gli altri +segmenti Linux utilizza la tecnica del \textit{copy on + write}\itindex{copy~on~write}; questa tecnica comporta che una pagina di +memoria viene effettivamente copiata per il nuovo processo solo quando ci +viene effettuata sopra una scrittura (e si ha quindi una reale differenza fra +padre e figlio). In questo modo si rende molto più efficiente il meccanismo +della creazione di un nuovo processo, non essendo più necessaria la copia di +tutto lo spazio degli indirizzi virtuali del padre, ma solo delle pagine di +memoria che sono state modificate, e solo al momento della modifica stessa. La differenza che si ha nei due processi è che nel processo padre il valore di ritorno della funzione \func{fork} è il \acr{pid} del processo figlio, mentre @@ -898,15 +900,17 @@ secondo lo specchietto riportato in tab.~\ref{tab:proc_waidpid_pid}. \textbf{Valore} & \textbf{Opzione} &\textbf{Significato}\\ \hline \hline - $<-1$& -- & attende per un figlio il cui \textit{process group} (vedi - sez.~\ref{sec:sess_proc_group}) è uguale al - valore assoluto di \param{pid}. \\ - $-1$ & \const{WAIT\_ANY} & attende per un figlio qualsiasi, usata in - questa maniera è equivalente a \func{wait}.\\ - $0$ & \const{WAIT\_MYPGRP} & attende per un figlio il cui \textit{process - group} è uguale a quello del processo chiamante. \\ - $>0$ & -- &attende per un figlio il cui \acr{pid} è uguale al - valore di \param{pid}.\\ + $<-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}. \\ + $-1$& \const{WAIT\_ANY} & attende per un figlio qualsiasi, usata in + questa maniera è equivalente a \func{wait}.\\ + $0$ &\const{WAIT\_MYPGRP}&attende per un figlio il cui + \itindex{process~group} \textit{process group} è + uguale a quello del processo chiamante. \\ + $>0$& -- & attende per un figlio il cui \acr{pid} è uguale + al valore di \param{pid}.\\ \hline \end{tabular} \caption{Significato dei valori dell'argomento \param{pid} della funzione @@ -1058,9 +1062,9 @@ processi in Unix 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 -creato un nuovo processo, la funzione semplicemente rimpiazza lo stack, lo -heap, i dati ed il testo del processo corrente con un nuovo programma letto da -disco. +creato un nuovo processo, la funzione semplicemente rimpiazza lo +\itindex{stack} stack, lo \itindex{heap} heap, i dati ed il testo del processo +corrente con un nuovo programma letto da disco. 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à @@ -1075,9 +1079,9 @@ famiglia di funzioni) che possono essere usate per questo compito, in realt \begin{errlist} \item[\errcode{EACCES}] il file non è eseguibile, oppure il filesystem è montato in \cmd{noexec}, oppure non è un file regolare o un interprete. - \item[\errcode{EPERM}] il file ha i bit \acr{suid} o \acr{sgid}, l'utente - non è root, il processo viene tracciato, o il filesystem è montato con - l'opzione \cmd{nosuid}. + \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}. \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 @@ -1213,8 +1217,8 @@ la lista completa (\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 \textit{process group-ID} - (\acr{pgid}), vedi sez.~\ref{sec:sess_proc_group}; +\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 @@ -1254,10 +1258,11 @@ Abbiamo detto che l'\textsl{user-ID reale} ed il \textsl{group-ID reale} restano gli stessi all'esecuzione di \func{exec}; lo stesso vale per l'\textsl{user-ID effettivo} ed il \textsl{group-ID effettivo} (il significato di questi identificatori è trattato in sez.~\ref{sec:proc_access_id}), tranne -quando il file che si va ad eseguire abbia o il \acr{suid} bit o lo \acr{sgid} -bit impostato, in questo caso l'\textsl{user-ID effettivo} ed il -\textsl{group-ID effettivo} vengono impostati rispettivamente all'utente o al -gruppo cui il file appartiene (per i dettagli vedi sez.~\ref{sec:proc_perms}). +quando il file che si va ad eseguire abbia o il \itindex{suid~bit}\acr{suid} +bit o lo \itindex{sgid~bit} \acr{sgid} bit impostato, in questo caso +l'\textsl{user-ID effettivo} ed il \textsl{group-ID effettivo} vengono +impostati rispettivamente all'utente o al gruppo cui il file appartiene (per i +dettagli vedi sez.~\ref{sec:proc_perms}). Se il file da eseguire è in formato \emph{a.out} e necessita di librerie condivise, viene lanciato il \textit{linker} dinamico \cmd{/lib/ld.so} prima @@ -1307,22 +1312,19 @@ problematiche connesse ad una gestione accorta dei privilegi. Come accennato in sez.~\ref{sec:intro_multiuser} il modello base\footnote{in realtà già esistono estensioni di questo modello base, che lo rendono più - flessibile e controllabile, come le - \itindex{capability}\textit{capabilities}, le ACL per i file o il - \textit{Mandatory Access Control} di SELinux; inoltre basandosi sul lavoro - effettuato con SELinux, a partire dal kernel 2.5.x, è iniziato lo sviluppo - di una infrastruttura di sicurezza, il \textit{Linux Security Modules}, o - LSM, in grado di fornire diversi agganci a livello del kernel per - modularizzare tutti i possibili controlli di accesso.} di sicurezza di un -sistema unix-like è fondato sui concetti di utente e gruppo, e sulla + flessibile e controllabile, come le \itindex{capabilities} + \textit{capabilities} illustrate in sez.~\ref{sec:proc_capabilities}, le ACL + per i file o il \textit{Mandatory Access Control} + \itindex{Mandatory~Access~Control~(MAC)} di SELinux; inoltre basandosi sul + lavoro effettuato con SELinux, a partire dal kernel 2.5.x, è iniziato lo + sviluppo di una infrastruttura di sicurezza, il \textit{Linux Security + Modules}, o LSM, in grado di fornire diversi agganci a livello del kernel + per modularizzare tutti i possibili controlli di accesso.} di sicurezza di +un sistema unix-like è fondato sui concetti di utente e gruppo, e sulla separazione fra l'amministratore (\textsl{root}, detto spesso anche \textit{superuser}) che non è sottoposto a restrizioni, ed il resto degli utenti, per i quali invece vengono effettuati i vari controlli di accesso. -%Benché il sistema sia piuttosto semplice (è basato su un solo livello di -% separazione) il sistema permette una -%notevole flessibilità, - 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 identificare uno specifico utente o un gruppo di utenti, per poi poter @@ -1406,12 +1408,13 @@ sez.~\ref{sec:file_perm_overview}). Questi identificatori normalmente sono identici ai corrispondenti del gruppo \textit{real} tranne nel caso in cui, come accennato in -sez.~\ref{sec:proc_exec}, il programma che si è posto in esecuzione abbia i bit -\acr{suid} o \acr{sgid} impostati (il significato di questi bit è affrontato -in dettaglio in sez.~\ref{sec:file_suid_sgid}). 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). +sez.~\ref{sec:proc_exec}, il programma che si è posto in esecuzione abbia i +bit \itindex{suid~bit} \acr{suid} o \itindex{sgid~bit} \acr{sgid} impostati +(il significato di questi bit è affrontato in dettaglio in +sez.~\ref{sec:file_suid_sgid}). In questo caso essi saranno impostati +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). Come nel caso del \acr{pid} e del \acr{ppid}, anche tutti questi identificatori possono essere letti attraverso le rispettive funzioni: @@ -1455,9 +1458,10 @@ 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 \acr{suid} o -\acr{sgid}. Essi quindi consentono di tenere traccia di quale fossero utente -e gruppo effettivi all'inizio dell'esecuzione di un nuovo programma. +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 un'estensione introdotta in Linux per rendere più sicuro l'uso di NFS @@ -1508,10 +1512,11 @@ all'\textsl{user-ID 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 \acr{suid} o \acr{sgid} impostati (vedi -sez.~\ref{sec:file_suid_sgid}) 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. +consentire ad un programma con i bit \itindex{suid~bit} \acr{suid} o +\itindex{sgid~bit} \acr{sgid} impostati (vedi sez.~\ref{sec:file_suid_sgid}) +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. Come esempio per chiarire l'uso di queste funzioni prendiamo quello con cui viene gestito l'accesso al file \file{/var/log/utmp}. In questo file viene @@ -1859,20 +1864,270 @@ compila con il flag \cmd{-ansi}, scrivere codice portabile. -\subsection{La gestione delle capabilities} +\subsection{La gestione delle \textit{capabilities}} \label{sec:proc_capabilities} -Da fare + +\itindbeg{capabilities} + +Come accennato in sez.~\ref{sec:proc_access_id} l'architettura classica della +gestione dei privilegi in un sistema unix-like ha il sostanziale problema di +fornire all'amministratore dei poteri troppo ampi, questo comporta che anche +quando di siamo predisposte delle protezioni per in essere in grado di +difendersi dagli effetti di una eventuale compromissione del sistema (come +montare un filesystem in sola lettura per impedirne modifiche), una volta che +questa sia stata effettuata e si siano ottenuti i privilegi di amministratore, +queste potranno essere comunque rimosse (nel caso dell'esempio si potrà sempre +rimontare il sistema in lettura-scrittura). + +Il problema consiste nel fatto che nell'architettura tradizionale di un +sistema unix-like i controlli di accesso sono basati su un solo livello di +separazione: per i processi normali essi sono posti in atto, mentre per i +processi con i privilegi di amministratore essi non vengono neppure eseguiti. +Dato che i privilegi sono sempre gli stessi, non esiste modo per evitare che +un processo con diritti di amministratore non possa eseguire certe operazioni. +Per ovviare a tutto ciò, a partire dai kernel della serie 2.2, è stato +introdotto un meccanismo, detto \textit{capabilities}, che consentisse di +suddividere i vari privilegi tradizionalmente associati all'amministratore in +un insieme di \textsl{capacità} distinte. + +Queste capacità possano essere abilitate e disabilitate in maniera +indipendente per ciascun processo, permettendo una granularità molto più fine +nella distribuzione dei privilegi. Il meccanismo completo delle +\textit{capabilities} prevederebbe anche la possibilità di associare le stesse +\textit{capabilities} anche ai singoli file +eseguibili,\footnote{l'implementazione di Linux si rifà ad una bozza per + quello che dovrebbe divenire lo standard POSIX.1e, che prevede questa + funzionalità.} in modo da poter stabilire quali capacità possono essere +utilizzate quando viene messo in esecuzione uno specifico programma; +attualmente\footnote{vale a dire almeno fino al kernel 2.6.13, e non è + disponibile al momento neanche nessuna realizzazione sperimentale.} questa +funzionalità non è implementata. + +Per gestire questo nuovo meccanismo ciascun processo porta con sé tre distinti +insiemi di \textit{capabilities}, che vengono denominati rispettivamente +\textit{effective}, \textit{permitted} ed \textit{inherited}. Questi insiemi +vengono mantenuti in forma di tre diverse maschere binarie,\footnote{il kernel + li mantiene, come i vari identificatori di sez.~\ref{sec:proc_setuid}, + all'interno della \struct{task\_struct} di ciascun processo (vedi + fig.~\ref{fig:proc_task_struct}), nei tre campi \texttt{cap\_effective}, + \texttt{cap\_inheritable}, \texttt{cap\_permitted} del tipo + \texttt{kernel\_cap\_t} (definito come intero a 32 bit), il che comporta un + massimo di 32 \textit{capabilities} distinte.} in cui ciascun bit +corrisponde ad una capacità diversa; se ne è riportato l'elenco,\footnote{si + tenga presente che l'elenco delle \textit{capabilities} presentato questa + tabella, ripreso dalla relativa pagina di manuale (accessibile con + \texttt{man capabilities}), è quello aggiornato al kernel 2.6.6.} con una +breve descrizione, ed il nome delle costanti che identificano i singoli bit, +in tab.~\ref{tab:proc_capabilities}. + + +\begin{table}[!hbt] + \centering + \footnotesize + \begin{tabular}{|l|p{12cm}|} + \hline + \textbf{Capacità}&\textbf{Descrizione}\\ + \hline + \hline + \const{CAP\_CHOWN} & la capacità di cambiare proprietario e gruppo + proprietario di un file (vedi + sez.~\ref{sec:file_chown}).\\ + \const{CAP\_DAC\_OVERRIDE}& la capacità di evitare il controllo dei + permessi di lettura, scrittura ed esecuzione dei + file, (vedi sez.~\ref{sec:file_access_control}) + caratteristici del modello classico del + controllo di accesso chiamato + \itindex{Discrectionary~Access~Control~(DAC)} + \textit{Discrectionary Access Control} (da cui + il nome DAC).\\ + \const{CAP\_DAC\_READ\_SEARCH}& la capacità di evitare il controllo dei + permessi di lettura, scrittura ed esecuzione per + le directory (vedi + sez.~\ref{sec:file_access_control}).\\ + \const{CAP\_FOWNER} & la capacità di evitare il controllo che + l'user-ID effettivo del processo (o meglio il + \textit{filesystem user-ID}, vedi + sez.~\ref{sec:proc_setuid}) coincida con + quello del proprietario di un file per tutte + le operazioni privilegiate non coperte dalle + precedenti \const{CAP\_DAC\_OVERRIDE} e + \const{CAP\_DAC\_READ\_SEARCH}. Queste + comprendono i cambiamenti dei permessi e dei + tempi del file (vedi sez.~\ref{sec:file_chmod} e + sez.~\ref{sec:file_utime}), le impostazioni degli + attributi estesi (con il comando \cmd{chattr}) e + delle ACL, poter ignorare lo + \itindex{sticky~bit} \textit{sticky bit} nella + cancellazione dei file (vedi + sez.~\ref{sec:file_sticky}), la possibilità di + impostare il flag di \const{O\_NOATIME} con + \func{open} e \func{fcntl} (vedi + sez.~\ref{sec:file_open} e + sez.~\ref{sec:file_fcntl}).\\ + \const{CAP\_FSETID} & la capacità di evitare la cancellazione + automatica dei bit \itindex{suid~bit} \acr{suid} + e \itindex{sgid~bit} \acr{sgid} quando un file + per i quali sono impostati viene modificato da + un processo senza questa capacità e la capacità + di impostare il bit \acr{sgid} su un file anche + quando questo è relativo ad un gruppo cui non si + appartiene (vedi sez.~\ref{sec:file_chmod}).\\ + \const{CAP\_IPC\_LOCK} & la capacità di effettuare il \textit{memory + locking} \itindex{memory~locking} con le + funzioni \func{mlock}, \func{mlockall}, + \func{shmctl}, \func{mmap} (vedi + sez.~\ref{sec:proc_mem_lock} e + sez.~\ref{sec:file_memory_map}). \\ + \const{CAP\_IPC\_OWNER} & la capacità di evitare il controllo dei permessi + per le operazioni sugli oggetti di + intercomunicazione fra processi (vedi + sez.~\ref{sec:ipc_sysv}).\\ + \const{CAP\_KILL} & la capacità di mandare segnali a qualunque + processo (vedi sez.~\ref{sec:sig_kill_raise}).\\ + \const{CAP\_LEASE} & la capacità di creare dei \textit{file lease} + \index{file!lease} su di un file (vedi + sez.~\ref{sec:file_asyncronous_lease}) + indipendentemente dalla proprietà dello + stesso.\footnotemark\\ + \const{CAP\_LINUX\_IMMUTABLE}& la capacità di impostare gli attributi + \textit{immutable} e \textit{append only} per i + file su un filesystem che supporta questi + attributi estesi.\\ + \const{CAP\_MKNOD} & la capacità di creare file di dispositivo con la + funzione \func{mknod} (vedi + sez.~\ref{sec:file_mknod}).\footnotemark\\ + \const{CAP\_NET\_ADMIN} & la capacità di eseguire alcune operazioni + privilegiate sulla rete (impostare le opzioni + privilegiate dei socket, abilitare il + multicasting, impostare interfacce di rete e + tabella di instradamento).\\ + \const{CAP\_NET\_BIND\_SERVICE}& la capacità di porre in ascolto server + su porte riservate (vedi + sez.~\ref{sec:TCP_func_bind}).\\ + \const{CAP\_NET\_BROADCAST}& la capacità di consentire l'uso di socket in + broadcast e multicast.\\ + \const{CAP\_NET\_RAW} & la capacità di usare socket \texttt{RAW} e + \texttt{PACKET} (quelli che permettono di creare + pacchetti nei protocolli di basso livello).\\ + \const{CAP\_SETGID} & la capacità di manipolare i group ID dei + processi, sia il principale che i supplementari, + (vedi sez.~\ref{sec:proc_setgroups} che quelli + trasmessi tramite i \index{socket} socket + \textit{unix domain} (vedi + sez.~\ref{sec:unix_socket}).\\ + \const{CAP\_SETPCAP} & la capacità di impostare o rimuovere una capacità + (limitatamente a quelle che il processo + chiamante ha nel suo insieme di capacità + permesse) da qualunque processo.\\ + \const{CAP\_SETUID} & la capacità di manipolare gli user ID del + processo (e trasmettere un valore arbitrario + tramite i socket unix domain).\\ + \const{CAP\_SYS\_ADMIN} & la capacità di eseguire una serie di compiti + amministrativi (come impostare le quote, + attivare e disattivare la swap, montare, + rimontare e smontare filesystem, ecc.). \\ + \const{CAP\_SYS\_BOOT} & la capacità di fare eseguire un reboot del + sistema.\\ + \const{CAP\_SYS\_CHROOT}& la capacità di eseguire la funzione + \func{chroot} (vedi + sez.~\ref{sec:file_chroot}).\\ + \const{CAP\_SYS\_MODULE}& la capacità di caricare e rimuovere moduli del + kernel. \\ + \const{CAP\_SYS\_NICE} & la capacità di modificare le priorità dei + processi (vedi sez.~\ref{sec:proc_priority}). \\ + \const{CAP\_SYS\_PACCT} & la capacità di usare le funzioni di + \textit{accounting} dei processi (vedi + sez.~\ref{sec:sys_bsd_accounting}).\\ + \const{CAP\_SYS\_RAWIO} & la capacità di eseguire operazioni sulle porte + di I/O con \func{ioperm} e \func{iopl} (vedi + sez.~\ref{sec:file_io_port}).\\ + \const{CAP\_SYS\_RESOURCE}& la capacità di superare le limitazioni sulle + risorse, aumentare le quote disco, usare lo + spazio disco riservato all'amministratore.\\ + \const{CAP\_SYS\_TIME} & la capacità di modificare il tempo di sistema + (vedi sez.~\ref{sec:sys_time}).\\ + \const{CAP\_SYS\_TTY\_CONFIG}& la capacità di simulare un \textit{hangup} + della console, con la funzione + \func{vhangup}.\\ + \const{CAP\_SYS\_PTRACE}& consente di tracciare qualunque processo con + \func{ptrace} (vedi + sez.~\ref{sec:xxx_ptrace}).\\ +% TODO documentatare ptrace + \hline + \end{tabular} + \caption{Le costanti che identificano le \textit{capabilities} presenti nel + kernel.} +\label{tab:proc_capabilities} +\end{table} + +\footnotetext{questa capacità è presente soltato a partire dai kernel della + serie 2.4.x.} + +\footnotetext{questa capacità è presente soltato a partire dai kernel della + serie 2.4.x.} + + +L'utilizzo di tre distinti insiemi serve a fornire una interfaccia flessibile +per l'uso delle \textit{capabilities}, con scopi analoghi a quelli per cui +sono mantenuti i diversi insiemi di identificatori di +sez.~\ref{sec:proc_setuid}; il loro significato è il seguente: +\begin{basedescript}{\desclabelwidth{2.0cm}\desclabelstyle{\nextlinelabel}} +\item[\textit{effective}] l'insieme delle \textit{capabilities} + ``\textsl{effettive}'', cioè quelle che vengono effettivamente usate dal + kernel per eseguire il controllo di accesso per le operazioni compiute dal + processo. +\item[\textit{permitted}] l'insieme delle \textit{capabilities} + ``\textsl{permesse}'', cioè l'insieme di quelle che un processo \textsl{può} + impostare come \textsl{effettive} se ha la capacità \const{CAP\_SETPCAP}. Se + un processo cancella una capacità da questo insieme non potrà più + riassumerla (almeno che non esegua un programma che è \acr{suid} di root). +\item[\textit{inherited}] l'insieme delle \textit{capabilities} + \textsl{ereditate}, cioè quelle che vengono trasmesse ad un nuovo programma + eseguito attraverso una chiamata ad \func{exec} (con l'eccezione del caso + che questo sia \acr{suid} di root). +\end{basedescript} + + +Oltre a questi tre insiemi relativi al singolo processo il kernel mantiene un +valore generale per tutto il sistema, chiamato +\index{capabilities~bounding~set} \textit{capabilities bounding set}. Questo +è un parametro di sistema, accessibile attraverso il contenuto del file +\file{/proc/sys/kernel/cap-bound}, che consente di impostare un limite +generale alle capacità che possono essere accordate ai vari processi. + +Il meccanismo prevede infatti che nell'esecuzione di una \func{exec} venga +utilizzato il valore mantenuto nell'insieme \textit{inherited} per +inizializzare tutti gli insiemi + + + +vengano +impostati come valori per le \textit{capabilities} (per tutti e tre gli +insiemi) del nuovo programma quelle + + + + + + + + + + + + +\itindend{capabilities} \section{La gestione della priorità di esecuzione} \label{sec:proc_priority} In questa sezione tratteremo più approfonditamente i meccanismi con il quale -lo \textit{scheduler}\itindex{scheduler} assegna la CPU ai vari -processi attivi. In particolare prenderemo in esame i vari meccanismi con cui -viene gestita l'assegnazione del tempo di CPU, ed illustreremo le varie -funzioni di gestione. +lo \textit{scheduler}\itindex{scheduler} assegna la CPU ai vari processi +attivi. In particolare prenderemo in esame i vari meccanismi con cui viene +gestita l'assegnazione del tempo di CPU, ed illustreremo le varie funzioni di +gestione. \subsection{I meccanismi di \textit{scheduling}} @@ -2105,9 +2360,10 @@ l'utente correnti. \param{which} & \param{who} & \textbf{Significato} \\ \hline \hline - \const{PRIO\_PROCESS} & \type{pid\_t} & processo \\ - \const{PRIO\_PRGR} & \type{pid\_t} & process group \\ - \const{PRIO\_USER} & \type{uid\_t} & utente \\ + \const{PRIO\_PROCESS} & \type{pid\_t} & processo \\ + \const{PRIO\_PRGR} & \type{pid\_t} & \itindex{process~group} + \textit{process group} \\ + \const{PRIO\_USER} & \type{uid\_t} & utente \\ \hline \end{tabular} \caption{Legenda del valore dell'argomento \param{which} e del tipo @@ -2719,10 +2975,11 @@ multi-thread, ma si hanno gli stessi problemi quando si vogliono chiamare delle funzioni all'interno dei gestori dei segnali. Fintanto che una funzione opera soltanto con le variabili locali è rientrante; -queste infatti vengono allocate nello stack, e un'altra invocazione non fa -altro che allocarne un'altra copia. Una funzione può non essere rientrante -quando opera su memoria che non è nello stack. Ad esempio una funzione non è -mai rientrante se usa una variabile globale o statica. +queste infatti vengono allocate nello \itindex{stack} stack, e un'altra +invocazione non fa altro che allocarne un'altra copia. Una funzione può non +essere rientrante quando opera su memoria che non è nello \itindex{stack} +stack. Ad esempio una funzione non è mai rientrante se usa una variabile +globale o statica. Nel caso invece la funzione operi su un oggetto allocato dinamicamente, la cosa viene a dipendere da come avvengono le operazioni: se l'oggetto è creato