Definizione nuova sezione per clone, prctl, ptrace. Correzioni varie e

prosucuzione del lavoro sulle capabilities.

diff --git a/fileadv.tex b/fileadv.tex
index 38f01fcf3d77be4a850bf90f374e33c2d29a1a67..2c4b09ad377dbb9ff01e75011542e46ece1a4f3f 100644 (file)
--- a/fileadv.tex
+++ b/fileadv.tex
@@ -8,6 +8,7 @@
 %% license is included in the section entitled "GNU Free Documentation
 %% License".
 %%
 %% license is included in the section entitled "GNU Free Documentation
 %% License".
 %%

+

 \chapter{La gestione avanzata dei file}
 \label{cha:file_advanced}
 In questo capitolo affronteremo le tematiche relative alla gestione avanzata
 \chapter{La gestione avanzata dei file}
 \label{cha:file_advanced}
 In questo capitolo affronteremo le tematiche relative alla gestione avanzata


@@ -189,11 +190,12 @@ riportate in tab.~\ref{tab:file_flock_operation}.
 \end{table}
 
 I primi due valori, \const{LOCK\_SH} e \const{LOCK\_EX} permettono di
 \end{table}
 
 I primi due valori, \const{LOCK\_SH} e \const{LOCK\_EX} permettono di

-richiedere un \textit{file lock}, ed ovviamente devono essere usati in maniera
-alternativa. Se si specifica anche \const{LOCK\_NB} la funzione non si
-bloccherà qualora il \textit{file lock} non possa essere acquisito, ma
-ritornerà subito con un errore di \errcode{EWOULDBLOCK}. Per rilasciare un
-\textit{file lock} si dovrà invece usare \const{LOCK\_UN}.
+richiedere un \textit{file lock} rispettivamente condiviso o esclusivo, ed
+ovviamente non possono essere usati insieme. Se con essi si specifica anche
+\const{LOCK\_NB} la funzione non si bloccherà qualora il \textit{file lock}
+non possa essere acquisito, ma ritornerà subito con un errore di
+\errcode{EWOULDBLOCK}. Per rilasciare un \textit{file lock} si dovrà invece
+usare direttamente const{LOCK\_UN}.

 
 Si tenga presente che non esiste una modalità per eseguire atomicamente un
 cambiamento del tipo di blocco (da \textit{shared lock} a \textit{esclusive
 
 Si tenga presente che non esiste una modalità per eseguire atomicamente un
 cambiamento del tipo di blocco (da \textit{shared lock} a \textit{esclusive


@@ -470,7 +472,7 @@ voce nella \itindex{file~table} \textit{file table}, ma con il valore del
 \acr{pid} del processo.
 
 \begin{figure}[!bht]
 \acr{pid} del processo.
 
 \begin{figure}[!bht]

-  \centering \includegraphics[width=13cm]{img/file_posix_lock}
+  \centering \includegraphics[width=12cm]{img/file_posix_lock}

   \caption{Schema dell'architettura del \textit{file locking}, nel caso
     particolare del suo utilizzo secondo l'interfaccia standard POSIX.}
   \label{fig:file_posix_lock}
   \caption{Schema dell'architettura del \textit{file locking}, nel caso
     particolare del suo utilizzo secondo l'interfaccia standard POSIX.}
   \label{fig:file_posix_lock}


@@ -5404,11 +5406,6 @@ livello di kernel.
 
 
 
 
 
 

-%\subsection{L'utilizzo delle porte di I/O}
-%\label{sec:file_io_port}
-%
-% TODO l'I/O sulle porte di I/O 
-% consultare le manpage di ioperm, iopl e outb

 
 % TODO non so dove trattarli, ma dal 2.6.39 ci sono i file handle, vedi
 % http://lwn.net/Articles/432757/ 
 
 % TODO non so dove trattarli, ma dal 2.6.39 ci sono i file handle, vedi
 % http://lwn.net/Articles/432757/ 

diff --git a/filedir.tex b/filedir.tex
index 17ea1df01231fe09c52c243dc3d68a3a567028ac..c3a284b976ade0fc31a5f3c9af1c8a8ede170446 100644 (file)
--- a/filedir.tex
+++ b/filedir.tex
@@ -4605,21 +4605,21 @@ Il meccanismo completo delle \textit{capabilities}\footnote{l'implementazione
   si rifà ad una bozza di quello che doveva diventare lo standard POSIX.1e,
   poi abbandonato.} prevede inoltre la possibilità di associare le stesse ai
 singoli file eseguibili, in modo da poter stabilire quali capacità possono
   si rifà ad una bozza di quello che doveva diventare lo standard POSIX.1e,
   poi abbandonato.} prevede inoltre la possibilità di associare le stesse ai
 singoli file eseguibili, in modo da poter stabilire quali capacità possono

-essere utilizzate quando viene messo in esecuzione uno specifico programma
-(una sorta di \acr{suid} anch'esso parcellizzato); ma il supporto per questa
-funzionalità, chiamata \textit{file capabilities}, è stato introdotto soltanto
-a partire dal kernel 2.6.24. Fino ad allora doveva essere il programma stesso
-ad eseguire una riduzione esplicita delle sue capacità, cosa che ha reso l'uso
-di questa funzionalità poco diffuso, vista la presenza di meccanismi
-alternativi per ottenere limitazioni delle capacità dell'amministratore a
-livello di sistema operativo, come \index{SELinux} SELinux.
+essere utilizzate quando viene messo in esecuzione uno specifico programma; ma
+il supporto per questa funzionalità, chiamata \textit{file capabilities}, è
+stato introdotto soltanto a partire dal kernel 2.6.24. Fino ad allora doveva
+essere il programma stesso ad eseguire una riduzione esplicita delle sue
+capacità, cosa che ha reso l'uso di questa funzionalità poco diffuso, vista la
+presenza di meccanismi alternativi per ottenere limitazioni delle capacità
+dell'amministratore a livello di sistema operativo, come \index{SELinux}
+SELinux.

 
 Con questo supporto e con le ulteriori modifiche introdotte con il kernel
 2.6.25 il meccanismo delle \textit{capabilities} è stato totalmente
 
 Con questo supporto e con le ulteriori modifiche introdotte con il kernel
 2.6.25 il meccanismo delle \textit{capabilities} è stato totalmente

-rivoluzionato, rendendolo più aderente alle intenzioni originali dello standard
-POSIX, rimuovendo il significato che fino ad allora aveva avuto la capacità
-\macro{CAP\_SETPCAP} e le modalità di funzionamento del cosiddetto
-\itindex{capabilities~bounding~set} \textit{capabilities bounding
+rivoluzionato, rendendolo più aderente alle intenzioni originali dello
+standard POSIX, rimuovendo il significato che fino ad allora aveva avuto la
+capacità \macro{CAP\_SETPCAP} e cambiando le modalità di funzionamento del
+cosiddetto \itindex{capabilities~bounding~set} \textit{capabilities bounding

   set}. Ulteriori modifiche sono state apportate con il kernel 2.6.26 per
 consentire la rimozione non ripristinabile dei privilegi di
 amministratore. Questo fa sì che il significato ed il comportamento del kernel
   set}. Ulteriori modifiche sono state apportate con il kernel 2.6.26 per
 consentire la rimozione non ripristinabile dei privilegi di
 amministratore. Questo fa sì che il significato ed il comportamento del kernel


@@ -4677,9 +4677,10 @@ altri tre insiemi associabili a ciascun file.\footnote{la realizzazione viene
   \macro{CAP\_SYS\_ADMIN}.} Le \textit{file capabilities} hanno effetto
 soltanto quando il file che le porta viene eseguito come programma con una
 \func{exec}, e forniscono un meccanismo che consente l'esecuzione dello stesso
   \macro{CAP\_SYS\_ADMIN}.} Le \textit{file capabilities} hanno effetto
 soltanto quando il file che le porta viene eseguito come programma con una
 \func{exec}, e forniscono un meccanismo che consente l'esecuzione dello stesso

-con maggiori privilegi; in sostanza sono una sorta di estensione dell'uso del
-\acr{suid} di root.  Anche questi tre insiemi sono identificati con gli stessi
-nomi, ma il loro significato è diverso:
+con maggiori privilegi; in sostanza sono una sorta di estensione del
+\acr{suid} bit limitato ai privilegi di amministratore. Anche questi tre
+insiemi sono identificati con gli stessi nomi di quello dei processi, ma il
+loro significato è diverso:

 \begin{basedescript}{\desclabelwidth{2.1cm}\desclabelstyle{\nextlinelabel}}
 \item[\textit{permitted}] (chiamato originariamente \textit{forced}) l'insieme
   delle capacità che con l'esecuzione del programma verranno aggiunte alle
 \begin{basedescript}{\desclabelwidth{2.1cm}\desclabelstyle{\nextlinelabel}}
 \item[\textit{permitted}] (chiamato originariamente \textit{forced}) l'insieme
   delle capacità che con l'esecuzione del programma verranno aggiunte alle


@@ -4741,14 +4742,14 @@ ruolo analogo al precedente nel passaggio attraverso una \func{exec}, come
 limite alle capacità che possono essere aggiunte al processo in quanto
 presenti nel \textit{permitted set} del programma messo in esecuzione, in
 sostanza il nuovo programma eseguito potrà ricevere una capacità presente nel
 limite alle capacità che possono essere aggiunte al processo in quanto
 presenti nel \textit{permitted set} del programma messo in esecuzione, in
 sostanza il nuovo programma eseguito potrà ricevere una capacità presente nel

-suo \textit{permitted set} solo se questa è anche nel \textit{bounding
-  set}. In questo modo si possono rimuovere definitivamente certe capacità da
-un processo, anche qualora questo dovesse eseguire un programma
-privilegiato. 
+suo \textit{permitted set} (quello del file) solo se questa è anche nel
+\textit{bounding set} (del processo). In questo modo si possono rimuovere
+definitivamente certe capacità da un processo, anche qualora questo dovesse
+eseguire un programma privilegiato che prevede di riassegnarle.

 
 Si tenga presente però che in questo caso il \textit{bounding set} blocca
 esclusivamente le capacità indicate nel \textit{permitted set} del programma
 
 Si tenga presente però che in questo caso il \textit{bounding set} blocca
 esclusivamente le capacità indicate nel \textit{permitted set} del programma

-che verrebbero attivate in caso di esecuzione, non quelle eventualmente già
+che verrebbero attivate in caso di esecuzione, e non quelle eventualmente già

 presenti nell'\textit{inheritable set} del processo (ad esempio perché
 presenti prima di averle rimosse dal \textit{bounding set}). In questo caso
 eseguendo un programma che abbia anche lui dette capacità nel suo
 presenti nell'\textit{inheritable set} del processo (ad esempio perché
 presenti prima di averle rimosse dal \textit{bounding set}). In questo caso
 eseguendo un programma che abbia anche lui dette capacità nel suo


@@ -4756,26 +4757,70 @@ eseguendo un programma che abbia anche lui dette capacità nel suo
 
 In questa seconda versione inoltre il \textit{bounding set} costituisce anche
 un limite per le capacità che possono essere aggiunte all'\textit{inheritable
 
 In questa seconda versione inoltre il \textit{bounding set} costituisce anche
 un limite per le capacità che possono essere aggiunte all'\textit{inheritable

-  set} del processo con \func{capset}, sempre nel senso che queste devono
-essere presenti nel \textit{bounding set} oltre che nel \textit{permitted set}
-del processo.
- 
-\itindend{capabilities~bounding~set}
- 
+  set} del processo stesso con \func{capset}, sempre nel senso che queste
+devono essere presenti nel \textit{bounding set} oltre che nel
+\textit{permitted set} del processo. Questo limite vale anche per processi con
+i privilegi di amministratore,\footnote{si tratta sempre di avere la
+  \textit{capability} \const{CAP\_SETPCAP}.} per i quali non vale la
+condizione che le \textit{capabilities} da aggiungere nell'\textit{inheritable
+  set} debbano essere presenti nel proprio \textit{permitted set}.\footnote{lo
+  scopo anche in questo caso è ottenere una rimozione definitiva della
+  possibilità di passare una capacità rimossa dal \textit{bounding set}.}
+

 Come si può notare per fare ricorso alle \textit{capabilities} occorre
 comunque farsi carico di una notevole complessità di gestione, aggravata dalla
 presenza di una radicale modifica del loro funzionamento con l'introduzione
 delle \textit{file capabilities}. Considerato che il meccanismo originale era
 incompleto e decisamente problematico nel caso di programmi che non ne
 Come si può notare per fare ricorso alle \textit{capabilities} occorre
 comunque farsi carico di una notevole complessità di gestione, aggravata dalla
 presenza di una radicale modifica del loro funzionamento con l'introduzione
 delle \textit{file capabilities}. Considerato che il meccanismo originale era
 incompleto e decisamente problematico nel caso di programmi che non ne

-sappiano tener conto,\footnote{si ebbe un grosso problema di sicurezza con
-  \texttt{sendmail}, riuscendo a rimuovere \const{CAP\_SETGID}
-  dall'\textit{inheritable set} si ottenne di far fallire una \func{setuid},
-  in maniera inaspettata per il programma (che aspettandosi il successo della
-  funzione non ne controllava lo stato di uscita) con la conseguenza di
-  effettuare come amministratore operazioni che altrimenti sarebbero state
-  eseguite, senza poter apportare danni, da utente normale.}  ci soffermeremo
-solo sulla implementazione completa presente a partire dal kernel 2.6.25,
-tralasciando ulteriori dettagli riguardo la versione precedente.
+sappessero tener conto,\footnote{si ebbe un grosso problema di sicurezza con
+  \texttt{sendmail}: riuscendo a rimuovere \const{CAP\_SETGID}
+  dall'\textit{inheritable set} di un processo si ottenne di far fallire
+  \func{setuid} in maniera inaspettata per il programma (che aspettandosi
+  sempre il successo della funzione non ne controllava lo stato di uscita) con
+  la conseguenza di effettuare come amministratore operazioni che altrimenti
+  sarebbero state eseguite, senza poter apportare danni, da utente normale.}
+ci soffermeremo solo sulla implementazione completa presente a partire dal
+kernel 2.6.25, tralasciando ulteriori dettagli riguardo la versione
+precedente.
+
+Riassumendo le regole finora illustrate tutte le \textit{capabilities} vengono
+ereditate senza modifiche attraverso una \func{fork} mentre, indicati con
+\texttt{orig\_*} i valori degli insiemi del processo chiamante, con
+\texttt{file\_*} quelli del file eseguito e con \texttt{bound\_set} il
+\textit{capabilities bounding set}, dopo l'invocazione di \func{exec} il
+processo otterrà dei nuovi insiemi di capacità \texttt{new\_*} secondo la
+formula (espressa in pseudocodice C) di fig.~\ref{fig:cap_across_exec}; si
+noti come in particolare il \textit{capabilities bounding set} non viene
+comunque modificato e resta lo stesso sia attraverso una \func{fork} che
+attraverso una \func{exec}.
+
+\begin{figure}[!htb]
+  \footnotesize \centering
+  \begin{minipage}[c]{12cm}
+    \includecodesnip{listati/cap-results.c}
+  \end{minipage}
+  \caption{Espressione della modifica delle \textit{capabilities} attraverso
+    una \func{exec}.}
+  \label{fig:cap_across_exec}
+\end{figure}
+
+\itindend{capabilities~bounding~set}
+
+A queste regole se ne aggiungono delle altre che servono a riprodurre il
+comportamento tradizionale di un sistema unix-like quando viene eseguito un
+file senza \textit{capabilities}, se si applicassero sempre così infatti, non
+essendo definite delle capacità né nel \textit{permitted set} né
+nell'\textit{inheritable set} del file, anche l'amministratore perderebbe
+tutti i privilegi eventualmente avuti dal processo.
+
+Per questo motivo se un programma senza \textit{capabilities} viene eseguito
+da un processo con \textit{real user-ID} 0, o se ha attivo il \acr{suid} bit
+ed appartiene all'amministratore, esso viene trattato come se tanto il
+\textit{permitted set} che l'\textit{inheritable set} fossero con tutte le
+\textit{capabilities} abilitate, e con l'\textit{effective set} attivo, col
+risultato di fornire comunque al processo tutte le capacità presenti nel
+proprio \textit{bounding set}.
+

 
 
 
 
 
 


@@ -4790,8 +4835,7 @@ ottiene tutte le \textit{capabilities} presenti nel \textit{capabilities
   bounding set}. In questo modo si può far si che ad un processo eseguito in
 un secondo tempo possano essere trasmesse solo un insieme limitato di
 capacità, impedendogli di recuperare quelle assenti nell'insieme
   bounding set}. In questo modo si può far si che ad un processo eseguito in
 un secondo tempo possano essere trasmesse solo un insieme limitato di
 capacità, impedendogli di recuperare quelle assenti nell'insieme

-\textit{inherited}. Si tenga presente invece che attraverso una \func{fork}
-vengono mantenute le stesse capacità del processo padre.
+\textit{inherited}. 

 
 
 % TODO verificare per process capability bounding set, vedi:
 
 
 % TODO verificare per process capability bounding set, vedi:


@@ -4931,10 +4975,10 @@ che è opportuno dettagliare maggiormente.
                               sez.~\ref{sec:sys_bsd_accounting}).\\ 
     \const{CAP\_SYS\_PTRACE}& La capacità di tracciare qualunque processo con
                               \func{ptrace} (vedi 
                               sez.~\ref{sec:sys_bsd_accounting}).\\ 
     \const{CAP\_SYS\_PTRACE}& La capacità di tracciare qualunque processo con
                               \func{ptrace} (vedi 

-                              sez.~\ref{sec:xxx_ptrace}).\\
+                              sez.~\ref{sec:process_ptrace}).\\

     \const{CAP\_SYS\_RAWIO} & La capacità di operare sulle porte
                               di I/O con \func{ioperm} e \func{iopl} (vedi
     \const{CAP\_SYS\_RAWIO} & La capacità di operare sulle porte
                               di I/O con \func{ioperm} e \func{iopl} (vedi

-                              sez.~\ref{sec:file_io_port}).\\
+                              sez.~\ref{sec:process_io_port}).\\

     \const{CAP\_SYS\_RESOURCE}& La capacità di superare le varie limitazioni
                               sulle risorse.\\ 
     \const{CAP\_SYS\_TIME}  & La capacità di modificare il tempo di sistema
     \const{CAP\_SYS\_RESOURCE}& La capacità di superare le varie limitazioni
                               sulle risorse.\\ 
     \const{CAP\_SYS\_TIME}  & La capacità di modificare il tempo di sistema


@@ -5020,9 +5064,8 @@ assegnare classi privilegiate per lo scheduling dell'I/O (vedi
 sez.~\ref{sec:io_priority}), superare il limite di sistema sul numero massimo
 di file aperti,\footnote{quello indicato da \procfile{/proc/sys/fs/file-max}.}
 effettuare operazioni privilegiate sulle chiavi mantenute dal kernel (vedi
 sez.~\ref{sec:io_priority}), superare il limite di sistema sul numero massimo
 di file aperti,\footnote{quello indicato da \procfile{/proc/sys/fs/file-max}.}
 effettuare operazioni privilegiate sulle chiavi mantenute dal kernel (vedi

-sez.~\ref{sec:io_priority}), usare la funzione \func{lookup\_dcookie} (vedi
-sez.~\ref{sec:xxx_profiling}), usare \const{CLONE\_NEWNS} con \func{unshare},
-(vedi sez.~\ref{sec:process_clone}).
+sez.~\ref{sec:io_priority}), usare la funzione \func{lookup\_dcookie}, usare
+\const{CLONE\_NEWNS} con \func{unshare}, (vedi sez.~\ref{sec:process_clone}).

 
 Originariamente \const{CAP\_SYS\_NICE} riguardava soltanto la capacità di
 aumentare le priorità di esecuzione dei processi, come la diminuzione del
 
 Originariamente \const{CAP\_SYS\_NICE} riguardava soltanto la capacità di
 aumentare le priorità di esecuzione dei processi, come la diminuzione del


@@ -5472,14 +5515,14 @@ funzione.
 
 % TODO vedi http://lwn.net/Articles/198557/ e 
 % http://www.madore.org/~david/linux/newcaps/
 
 % TODO vedi http://lwn.net/Articles/198557/ e 
 % http://www.madore.org/~david/linux/newcaps/

-% TODO documentare prctl ...
+

 
 
 \subsection{La funzione \func{chroot}}
 \label{sec:file_chroot}
 
 % TODO introdurre nuova sezione sulle funzionalità di sicurezza avanzate, con
 
 
 \subsection{La funzione \func{chroot}}
 \label{sec:file_chroot}
 
 % TODO introdurre nuova sezione sulle funzionalità di sicurezza avanzate, con

-% dentro chroot SELinux e AppArmor ???
+% dentro chroot SELinux e AppArmor, Tomoyo, Smack, cgroup o che altro ???

 
 Benché non abbia niente a che fare con permessi, utenti e gruppi, la funzione
 \func{chroot} viene usata spesso per restringere le capacità di accesso di un
 
 Benché non abbia niente a che fare con permessi, utenti e gruppi, la funzione
 \func{chroot} viene usata spesso per restringere le capacità di accesso di un


@@ -5616,7 +5659,7 @@ programmi e librerie) di cui il server potrebbe avere bisogno.
 % LocalWords:  setresuid setfsuid IMMUTABLE immutable append only BIND SERVICE
 % LocalWords:  BROADCAST broadcast multicast multicasting RAW PACKET IPC LOCK
 % LocalWords:  memory mlock mlockall shmctl mmap MODULE RAWIO ioperm iopl PACCT
 % LocalWords:  setresuid setfsuid IMMUTABLE immutable append only BIND SERVICE
 % LocalWords:  BROADCAST broadcast multicast multicasting RAW PACKET IPC LOCK
 % LocalWords:  memory mlock mlockall shmctl mmap MODULE RAWIO ioperm iopl PACCT

-% LocalWords:  PTRACE ptrace accounting NICE RESOURCE TTY CONFIG hangup vhangup
+% LocalWords:  ptrace accounting NICE RESOURCE TTY CONFIG hangup vhangup

 % LocalWords:  LEASE lease SETFCAP AUDIT permitted inherited inheritable AND
 % LocalWords:  bounding execve fork capget capset header hdrp datap ESRCH undef
 % LocalWords:  version libcap lcap clear ncap caps pag capgetp CapInh CapPrm
 % LocalWords:  LEASE lease SETFCAP AUDIT permitted inherited inheritable AND
 % LocalWords:  bounding execve fork capget capset header hdrp datap ESRCH undef
 % LocalWords:  version libcap lcap clear ncap caps pag capgetp CapInh CapPrm


@@ -5627,11 +5670,11 @@ programmi e librerie) di cui il server potrebbe avere bisogno.
 % LocalWords:  QUOTAON ENODEV ENOPKG ENOTBLK GETQUOTA SETQUOTA SETUSE SETQLIM
 % LocalWords:  forced allowed sendmail SYSLOG WAKE ALARM CLOCK BOOTTIME dqstats
 % LocalWords:  REALTIME securebits GETSTATS QFMT curspace curinodes btime itime
 % LocalWords:  QUOTAON ENODEV ENOPKG ENOTBLK GETQUOTA SETQUOTA SETUSE SETQLIM
 % LocalWords:  forced allowed sendmail SYSLOG WAKE ALARM CLOCK BOOTTIME dqstats
 % LocalWords:  REALTIME securebits GETSTATS QFMT curspace curinodes btime itime

+% LocalWords:  QIF BLIMITS bhardlimit bsoftlimit ILIMITS ihardlimit isoftlimit
+% LocalWords:  INODES LIMITS USAGE valid dqi IIF BGRACE bgrace IGRACE igrace
+% LocalWords:  Python Truelite Srl quotamodule Repository who

 
 %%% Local Variables: 
 %%% mode: latex
 %%% TeX-master: "gapil"
 %%% End: 
 
 %%% Local Variables: 
 %%% mode: latex
 %%% TeX-master: "gapil"
 %%% End: 

-% LocalWords:  QIF BLIMITS bhardlimit bsoftlimit ILIMITS ihardlimit isoftlimit
-% LocalWords:  INODES LIMITS USAGE valid dqi IIF BGRACE bgrace IGRACE igrace
-% LocalWords:  Python Truelite Srl quotamodule Repository who

diff --git a/prochand.tex b/prochand.tex
index 8113d7f095f6f82e73022095fc1fcea78c472150..be5e9767554d85d7b5ef362e49dcaf4d0fdd3dc5 100644 (file)
--- a/prochand.tex
+++ b/prochand.tex
@@ -670,7 +670,7 @@ Le differenze fra padre e figlio dopo la \func{fork} invece sono:\footnote{a
   sez.~\ref{sec:sig_notification}), che non vengono ereditate dal figlio;
 \item le mappature di memoria marcate come \const{MADV\_DONTFORK} (vedi
   sez.~\ref{sec:file_memory_map}) che non vengono ereditate dal figlio;
   sez.~\ref{sec:sig_notification}), che non vengono ereditate dal figlio;
 \item le mappature di memoria marcate come \const{MADV\_DONTFORK} (vedi
   sez.~\ref{sec:file_memory_map}) che non vengono ereditate dal figlio;

-\item l'impostazione con \func{prctl} (vedi sez.~\ref{sec:prctl_xxx}) che
+\item l'impostazione con \func{prctl} (vedi sez.~\ref{sec:process_prctl}) che

   notifica al figlio la terminazione del padre viene cancellata;
 \item il segnale di terminazione del figlio è sempre \const{SIGCHLD} anche
   qualora nel padre fosse stato modificato (vedi sez.~\ref{sec:process_clone}). 
   notifica al figlio la terminazione del padre viene cancellata;
 \item il segnale di terminazione del figlio è sempre \const{SIGCHLD} anche
   qualora nel padre fosse stato modificato (vedi sez.~\ref{sec:process_clone}). 


@@ -1032,11 +1032,11 @@ quando un processo figlio entra nello stato \textit{stopped}\footnote{in
   realtà viene notificato soltanto il caso in cui il processo è stato fermato
   da un segnale di stop (vedi sez.~\ref{sec:sess_ctrl_term}), e non quello in
   cui lo stato \textit{stopped} è dovuto all'uso di \func{ptrace} (vedi
   realtà viene notificato soltanto il caso in cui il processo è stato fermato
   da un segnale di stop (vedi sez.~\ref{sec:sess_ctrl_term}), e non quello in
   cui lo stato \textit{stopped} è dovuto all'uso di \func{ptrace} (vedi

-  sez.~\ref{sec:xxx_ptrace}).} (vedi tab.~\ref{tab:proc_proc_states}), mentre
-con \const{WCONTINUED} la funzione ritorna quando un processo in stato
+  sez.~\ref{sec:process_ptrace}).} (vedi tab.~\ref{tab:proc_proc_states}),
+mentre con \const{WCONTINUED} la funzione ritorna quando un processo in stato

 \textit{stopped} riprende l'esecuzione per la ricezione del segnale
 \const{SIGCONT} (l'uso di questi segnali per il controllo di sessione è
 \textit{stopped} riprende l'esecuzione per la ricezione del segnale
 \const{SIGCONT} (l'uso di questi segnali per il controllo di sessione è

-dettagliato in sez.~\ref{sec:sess_ctrl_term}). 
+dettagliato 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
 
 La terminazione di un processo figlio (così come gli altri eventi osservabili
 con \func{waitpid}) è chiaramente un evento asincrono rispetto all'esecuzione


@@ -1539,11 +1539,11 @@ nell'esecuzione della funzione \func{exec}, queste sono:
   sez.~\ref{sec:thread_xxx}) sono cancellati e tutti gli oggetti ad essi
   relativi (vedi sez.~\ref{sec:thread_xxx}) rimossi;
 \item viene impostato il flag \const{PR\_SET\_DUMPABLE} di \func{prctl} (vedi
   sez.~\ref{sec:thread_xxx}) sono cancellati e tutti gli oggetti ad essi
   relativi (vedi sez.~\ref{sec:thread_xxx}) rimossi;
 \item viene impostato il flag \const{PR\_SET\_DUMPABLE} di \func{prctl} (vedi

-  sez.~\ref{sec:prctl_xxx}) a meno che il programma da eseguire non sia
+  sez.~\ref{sec:process_prctl}) a meno che il programma da eseguire non sia

   \itindex{suid~bit} \acr{suid} o \itindex{sgid~bit} \acr{sgid} (vedi
   sez.~\ref{sec:proc_access_id});
 \item il flag \const{PR\_SET\_KEEPCAPS} di \func{prctl} (vedi
   \itindex{suid~bit} \acr{suid} o \itindex{sgid~bit} \acr{sgid} (vedi
   sez.~\ref{sec:proc_access_id});
 \item il flag \const{PR\_SET\_KEEPCAPS} di \func{prctl} (vedi

-  sez.~\ref{sec:prctl_xxx}) viene cancellato;
+  sez.~\ref{sec:process_prctl}) viene cancellato;

 \item il nome del processo viene impostato al nome del file contenente il
   programma messo in esecuzione;
 \item il segnale di terminazione viene reimpostato a \const{SIGCHLD};
 \item il nome del processo viene impostato al nome del file contenente il
   programma messo in esecuzione;
 \item il segnale di terminazione viene reimpostato a \const{SIGCHLD};


@@ -3262,11 +3262,14 @@ 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
   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 dello stesso, solo
+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
 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} o \const{IOPRIO\_CLASS\_IDLE}.
+\const{IOPRIO\_CLASS\_RT}, lo stesso privilegio era richiesto anche per la
+classe \const{IOPRIO\_CLASS\_IDLE} fino al kernel 2.6.24, ma dato che in
+questo caso non ci sono effetti sugli altri processi questo limite è stato
+rimosso a partire dal kernel 2.6.25.

 
 %TODO verificare http://lwn.net/Articles/355987/
 
 
 %TODO verificare http://lwn.net/Articles/355987/
 


@@ -3274,6 +3277,40 @@ impostare un processo ad una priorità di I/O nella classe
 % vedi man numa e le pagine di manuale relative
 % vedere anche dove metterle...
 
 % vedi man numa e le pagine di manuale relative
 % vedere anche dove metterle...
 

+
+\section{Funzioni di gestione avanzata}
+\label{sec:proc_advanced_control}
+
+Nelle precedenti sezioni si sono trattate la gran parte delle funzioni che
+attengono alla gestione ordinaria dei processi e delle loro proprietà più
+comuni. Tratteremo qui alcune \textit{system call} specialistiche dedicate
+alla gestione di alcune funzionalità specifiche ed avanzate il cui uso è in
+genere piuttosto ridotto.
+
+\subsection{La system call \func{clone}}
+\label{sec:process_clone}
+
+Da fare
+
+\subsection{La funzione \func{prctl}}
+\label{sec:process_prctl}
+
+Da fare
+
+\subsection{La funzione \func{ptrace}}
+\label{sec:process_ptrace}
+
+Da fare
+
+\subsection{L'accesso alle porte di I/O}
+\label{sec:process_io_port}
+
+%
+% TODO l'I/O sulle porte di I/O 
+% consultare le manpage di ioperm, iopl e outb
+
+Da fare
+

 \section{Problematiche di programmazione multitasking}
 \label{sec:proc_multi_prog}
 
 \section{Problematiche di programmazione multitasking}
 \label{sec:proc_multi_prog}
 

diff --git a/system.tex b/system.tex
index 2c7cf2d4ef0047dfb00634269efab8a9f47e99df..12ed77c9fe12256b9b7a3dce63c7719011a79ef3 100644 (file)
--- a/system.tex
+++ b/system.tex
@@ -559,7 +559,7 @@ lettura.  Affronteremo questi argomenti in questa sezione, insieme alle
 funzioni che si usano per il controllo di altre caratteristiche generali del
 sistema, come quelle per la gestione dei filesystem e di utenti e gruppi.
 
 funzioni che si usano per il controllo di altre caratteristiche generali del
 sistema, come quelle per la gestione dei filesystem e di utenti e gruppi.
 

-% TODO ristrutturare e aggiungere \func{prctl}
+% TODO ristrutturare ?

 
 \subsection{La funzione \func{sysctl} ed il filesystem \file{/proc}}
 \label{sec:sys_sysctl}
 
 \subsection{La funzione \func{sysctl} ed il filesystem \file{/proc}}
 \label{sec:sys_sysctl}

diff --git a/thread.tex b/thread.tex
index 8cc4facf0c65e0f0896284e964558fae976e8fe5..39c1f16ebd4b8ca1bc156efb458457a30d26ba33 100644 (file)
--- a/thread.tex
+++ b/thread.tex
@@ -61,9 +61,6 @@ dei processi:
 \label{sec:linux_thread}
 
 
 \label{sec:linux_thread}
 
 

-\subsection{La system call \func{clone}}
-\label{sec:process_clone}
-

 
 
 \subsection{Implementazioni alternative}
 
 
 \subsection{Implementazioni alternative}