Materiale su clone, inizio

diff --git a/filedir.tex b/filedir.tex
index a48b85860f4c3d932f5510da27d5bfce06bff533..88c392e6f0f9d860855d20a440334297e36f642c 100644 (file)
--- a/filedir.tex
+++ b/filedir.tex
@@ -4870,7 +4870,7 @@ cancellarle dal \textit{permitted set}.
 
 Per questo motivo a partire dal kernel 2.6.26, se le \textit{file
   capabilities} sono abilitate, ad ogni processo viene stata associata una
 
 Per questo motivo a partire dal kernel 2.6.26, se le \textit{file
   capabilities} sono abilitate, ad ogni processo viene stata associata una

-ulteriore maschera binaria, chiamata \textit{securebits flags}, il cui sono
+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
 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


@@ -5143,8 +5143,8 @@ operazioni;\footnote{vale a dire la richiesta che l'user-ID effettivo del
   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
   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

-impostazioni degli attributi estesi e delle ACL (vedi
-sez.~\ref{sec:file_xattr} e \ref{sec:file_ACL}), poter ignorare lo
+impostazioni degli attributi dei file (vedi sez.~\ref{sec:file_ioctl}) e delle
+ACL (vedi sez.~\ref{sec:file_xattr} e \ref{sec:file_ACL}), poter ignorare lo

 \itindex{sticky~bit} \textit{sticky bit} nella cancellazione dei file (vedi
 sez.~\ref{sec:file_special_perm}), la possibilità di impostare il flag di
 \const{O\_NOATIME} con \func{open} e \func{fcntl} (vedi
 \itindex{sticky~bit} \textit{sticky bit} nella cancellazione dei file (vedi
 sez.~\ref{sec:file_special_perm}), la possibilità di impostare il flag di
 \const{O\_NOATIME} con \func{open} e \func{fcntl} (vedi


@@ -5173,7 +5173,7 @@ 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:keyctl_management}), usare la funzione \func{lookup\_dcookie},
 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:keyctl_management}), usare la funzione \func{lookup\_dcookie},

-usare \const{CLONE\_NEWNS} con \func{unshare}, (vedi
+usare \const{CLONE\_NEWNS} con \func{unshare} e \func{clone}, (vedi

 sez.~\ref{sec:process_clone}).
 
 Originariamente \const{CAP\_SYS\_NICE} riguardava soltanto la capacità di
 sez.~\ref{sec:process_clone}).
 
 Originariamente \const{CAP\_SYS\_NICE} riguardava soltanto la capacità di


@@ -5196,7 +5196,6 @@ risorse di un processo (vedi sez.~\ref{sec:sys_resource_limit}) e quelle sul
 numero di processi, ed i limiti sulle dimensioni dei messaggi delle code del
 SysV IPC (vedi sez.~\ref{sec:ipc_sysv_mq}).
 
 numero di processi, ed i limiti sulle dimensioni dei messaggi delle code del
 SysV IPC (vedi sez.~\ref{sec:ipc_sysv_mq}).
 

-

 Per la gestione delle \textit{capabilities} il kernel mette a disposizione due
 funzioni che permettono rispettivamente di leggere ed impostare i valori dei
 tre insiemi illustrati in precedenza. Queste due funzioni sono \funcd{capget}
 Per la gestione delle \textit{capabilities} il kernel mette a disposizione due
 funzioni che permettono rispettivamente di leggere ed impostare i valori dei
 tre insiemi illustrati in precedenza. Queste due funzioni sono \funcd{capget}


@@ -5226,7 +5225,6 @@ loro rispettivi prototipi sono:
   \end{errlist}
   ed inoltre \errval{EFAULT} ed \errval{EINVAL}.
 }
   \end{errlist}
   ed inoltre \errval{EFAULT} ed \errval{EINVAL}.
 }

-

 \end{functions}
 
 Queste due funzioni prendono come argomenti due tipi di dati dedicati,
 \end{functions}
 
 Queste due funzioni prendono come argomenti due tipi di dati dedicati,


@@ -5433,8 +5431,9 @@ di tipo \type{cap\_flag\_t} che può assumere esclusivamente\footnote{si tratta
   definizione che si trova in \texttt{/usr/include/sys/capability.h}.} uno dei
 valori illustrati in tab.~\ref{tab:cap_set_identifier}.
 
   definizione che si trova in \texttt{/usr/include/sys/capability.h}.} uno dei
 valori illustrati in tab.~\ref{tab:cap_set_identifier}.
 

-Si possono inoltre confrontare in maniera diretta due \textit{capability
-  state} con la funzione \funcd{cap\_compare}; il suo prototipo è:
+Si possono inoltre confrontare in maniera diretta due diversi
+\textit{capability state} con la funzione \funcd{cap\_compare}; il suo
+prototipo è:

 \begin{functions}
   \headdecl{sys/capability.h}
   \funcdecl{int cap\_compare(cap\_t cap\_a, cap\_t cap\_b)}
 \begin{functions}
   \headdecl{sys/capability.h}
   \funcdecl{int cap\_compare(cap\_t cap\_a, cap\_t cap\_b)}


@@ -5590,7 +5589,7 @@ o negli insiemi specificati, ignorando tutto il resto. I due operatori possono
 anche essere combinati nella stessa proposizione, per aggiungere e togliere le
 capacità dell'elenco da insiemi diversi.
 
 anche essere combinati nella stessa proposizione, per aggiungere e togliere le
 capacità dell'elenco da insiemi diversi.
 

-La assegnazione si applica invece su tutti gli insiemi allo stesso tempo,
+L'assegnazione si applica invece su tutti gli insiemi allo stesso tempo,

 pertanto l'uso di ``\texttt{=}'' è equivalente alla cancellazione preventiva
 di tutte le capacità ed alla impostazione di quelle elencate negli insiemi
 specificati, pertanto in genere lo si usa una sola volta all'inizio della
 pertanto l'uso di ``\texttt{=}'' è equivalente alla cancellazione preventiva
 di tutte le capacità ed alla impostazione di quelle elencate negli insiemi
 specificati, pertanto in genere lo si usa una sola volta all'inizio della


@@ -5608,8 +5607,9 @@ privilegi di amministratore avrà una rappresentazione nella forma
 in quanto per le regole viste a pag.~\ref{sec:capability-uid-transition} le
 capacità verranno attivate attraverso una \func{exec}). Infine, come esempio
 meno banale, otterremo per \texttt{init} una rappresentazione nella forma
 in quanto per le regole viste a pag.~\ref{sec:capability-uid-transition} le
 capacità verranno attivate attraverso una \func{exec}). Infine, come esempio
 meno banale, otterremo per \texttt{init} una rappresentazione nella forma

-``\texttt{=ep cap\_setpcap-e}'' dato che come accennato tradizionalmente
-\const{CAP\_SETPCAP} è sempre stata rimossa da detto processo.
+``\texttt{=ep cap\_setpcap-e}'' dato che come accennato tradizionalmente la
+\textit{capability} \const{CAP\_SETPCAP} è sempre stata rimossa da detto
+processo.

 
 Viceversa per passare ottenere un \textit{capability state} dalla sua
 rappresentazione testuale si può usare \funcd{cap\_from\_text}, il cui
 
 Viceversa per passare ottenere un \textit{capability state} dalla sua
 rappresentazione testuale si può usare \funcd{cap\_from\_text}, il cui


@@ -5647,7 +5647,7 @@ Linux ed i rispettivi prototipi sono:
   
   \bodydesc{La funzione \func{cap\_to\_name} ritorna un valore diverso da
     \val{NULL} in caso di successo e \val{NULL} in caso di errore, mentre
   
   \bodydesc{La funzione \func{cap\_to\_name} ritorna un valore diverso da
     \val{NULL} in caso di successo e \val{NULL} in caso di errore, mentre

-    \func{cap\_to\_name} ritorna rispettivamente 0 e $-1$, per entrambe in
+    \func{cap\_to\_name} ritorna rispettivamente 0 e $-1$; per entrambe in

     caso di errore \var{errno} può assumere i valori \errval{EINVAL} o
     \errval{ENOMEM}.  }
 \end{functions}
     caso di errore \var{errno} può assumere i valori \errval{EINVAL} o
     \errval{ENOMEM}.  }
 \end{functions}


@@ -5659,10 +5659,11 @@ da \param{cap\_p} il valore della capacità rappresentata dalla
 stringa \param{name}.
 
 Fin quei abbiamo trattato solo le funzioni di servizio relative alla
 stringa \param{name}.
 
 Fin quei abbiamo trattato solo le funzioni di servizio relative alla

-manipolazione dei \textit{capability state}; l'interfaccia di gestione prevede
-però anche le funzioni per la gestione delle \textit{capabilities} stesse. La
-prima di queste è \funcd{cap\_get\_proc} che consente la lettura delle
-\textit{capabilities} del processo corrente, il suo prototipo è:
+manipolazione dei \textit{capability state} come strutture di dati;
+l'interfaccia di gestione prevede però anche le funzioni per trattare le
+\textit{capabilities} presenti nei processi. La prima di queste funzioni è
+\funcd{cap\_get\_proc} che consente la lettura delle \textit{capabilities} del
+processo corrente, il suo prototipo è:

 \begin{functions}
   \headdecl{sys/capability.h}
 
 \begin{functions}
   \headdecl{sys/capability.h}
 

diff --git a/fileunix.tex b/fileunix.tex
index 18fb5d8d660bb81d1f13dfd9120a13adc75c1117..5e3a39afbb58e61c447d03ab53aebd10ebbd1121 100644 (file)
--- a/fileunix.tex
+++ b/fileunix.tex
@@ -1685,7 +1685,6 @@ operazioni che sono predefinite per qualunque file,\footnote{in particolare
 
 % TODO aggiungere FIBMAP e FIEMAP, vedi http://lwn.net/Articles/260832
 
 
 % TODO aggiungere FIBMAP e FIEMAP, vedi http://lwn.net/Articles/260832
 

-

 Si noti però come la gran parte di queste operazioni specifiche dei file (per
 essere precisi le prime sei dell'elenco) siano effettuabili in maniera
 generica anche tramite l'uso di \func{fcntl}. Le due funzioni infatti sono
 Si noti però come la gran parte di queste operazioni specifiche dei file (per
 essere precisi le prime sei dell'elenco) siano effettuabili in maniera
 generica anche tramite l'uso di \func{fcntl}. Le due funzioni infatti sono

diff --git a/process.tex b/process.tex
index 09b2ea56d06a6865d3f0180c5a873023d50fe904..d3fe9c504020b81433a0c5b6fd372e919a8d72cf 100644 (file)
--- a/process.tex
+++ b/process.tex
@@ -444,10 +444,10 @@ seguenti segmenti:
     automaticamente il codice necessario, seguendo quella che viene chiamata
     una \textit{calling convention}; quella standard usata con il C ed il C++
     è detta \textit{cdecl} e prevede che gli argomenti siano caricati nello
     automaticamente il codice necessario, seguendo quella che viene chiamata
     una \textit{calling convention}; quella standard usata con il C ed il C++
     è detta \textit{cdecl} e prevede che gli argomenti siano caricati nello

-    \textit{stack} dal chiamante da destra a sinistra, e che si il chiamante
+    \textit{stack} dal chiamante da destra a sinistra, e che sia il chiamante

     stesso ad eseguire la ripulitura dello \textit{stack} al ritorno della
     funzione, se ne possono però utilizzare di alternative (ad esempio nel
     stesso ad eseguire la ripulitura dello \textit{stack} al ritorno della
     funzione, se ne possono però utilizzare di alternative (ad esempio nel

-    pascal gli argomenti sono inseriti da sinistra a destra ed è compito del
+    Pascal gli argomenti sono inseriti da sinistra a destra ed è compito del

     chiamato ripulire lo \textit{stack}), in genere non ci si deve preoccupare
     di questo fintanto che non si mescolano funzioni scritte con linguaggi
     diversi.}
     chiamato ripulire lo \textit{stack}), in genere non ci si deve preoccupare
     di questo fintanto che non si mescolano funzioni scritte con linguaggi
     diversi.}

diff --git a/prochand.tex b/prochand.tex
index 78ad88dc6a075976334798c187b67e4d38c74f03..8120b9f6f55b8794c4ba694f6637922196b5a72c 100644 (file)
--- a/prochand.tex
+++ b/prochand.tex
@@ -310,9 +310,9 @@ affrontato in dettaglio in sez.~\ref{sec:proc_perms}.
 La funzione \funcd{fork} è la funzione fondamentale della gestione dei
 processi: come si è detto tradizionalmente l'unico modo di creare un nuovo
 processo era attraverso l'uso di questa funzione,\footnote{in realtà oggi la
 La funzione \funcd{fork} è la funzione fondamentale della gestione dei
 processi: come si è detto tradizionalmente l'unico modo di creare un nuovo
 processo era attraverso l'uso di questa funzione,\footnote{in realtà oggi la

-  system call usata più comunemente da Linux per creare nuovi processi è
-  \func{clone} (vedi \ref{sec:process_clone}) , anche perché a partire dalle
-  \acr{glibc} 2.3.3 non viene più usata la system call originale, ma la stessa
+  \textit{system call} usata da Linux per creare nuovi processi è \func{clone}
+  (vedi \ref{sec:process_clone}), anche perché a partire dalle \acr{glibc}
+  2.3.3 non viene più usata la \textit{system call} originale, ma la stessa

   \func{fork} viene implementata tramite \func{clone}, cosa che consente una
   migliore interazione coi \textit{thread}.} essa quindi riveste un ruolo
 centrale tutte le volte che si devono scrivere programmi che usano il
   \func{fork} viene implementata tramite \func{clone}, cosa che consente una
   migliore interazione coi \textit{thread}.} essa quindi riveste un ruolo
 centrale tutte le volte che si devono scrivere programmi che usano il


@@ -693,8 +693,8 @@ venne introdotta in BSD per migliorare le prestazioni.
 
 Dato che Linux supporta il \itindex{copy~on~write} \textit{copy on write} la
 perdita di prestazioni è assolutamente trascurabile, e l'uso di questa
 
 Dato che Linux supporta il \itindex{copy~on~write} \textit{copy on write} la
 perdita di prestazioni è assolutamente trascurabile, e l'uso di questa

-funzione, che resta un caso speciale della system call \func{clone} (che
-tratteremo in dettaglio in sez.~\ref{sec:process_clone}) è deprecato; per
+funzione, che resta un caso speciale della \textit{system call} \func{clone}
+(che tratteremo in dettaglio in sez.~\ref{sec:process_clone}) è deprecato; per

 questo eviteremo di trattarla ulteriormente.
 
 
 questo eviteremo di trattarla ulteriormente.
 
 


@@ -983,9 +983,9 @@ deve essere specificato come maschera binaria dei flag riportati nella prima
 parte in tab.~\ref{tab:proc_waitpid_options} che possono essere combinati 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
 parte in tab.~\ref{tab:proc_waitpid_options} che possono essere combinati 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 system call generica
-\func{clone} (vedi sez.~\ref{sec:process_clone}) usati principalmente per la
-gestione della terminazione dei \itindex{thread} \textit{thread} (vedi
+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}).
 
 \begin{table}[!htb]
 sez.~\ref{sec:thread_xxx}).
 
 \begin{table}[!htb]


@@ -3288,15 +3288,60 @@ 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} dedicate alla gestione di
 funzionalità dei processi molto specifiche ed avanzate, il cui uso è in genere
 attengono alla gestione ordinaria dei processi e delle loro proprietà più
 comuni. Tratteremo qui alcune \textit{system call} dedicate alla gestione di
 funzionalità dei processi molto specifiche ed avanzate, il cui uso è in genere

-piuttosto ridotto. Trattandosi di problematiche relativamente complesse, che
-spesso presuppongono la conoscenza di altri argomenti trattati più avanti
-nella guida, si può saltare questa lezione ad una prima lettura, tornando su
+piuttosto ridotto. Trattandosi di problematiche abbastanza complesse, che
+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 system call \func{clone}}
 \label{sec:process_clone}
 
 di essa in un secondo tempo.
 
 \subsection{La system call \func{clone}}
 \label{sec:process_clone}
 

-Da fare
+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 ulteriore supporto per
+le varie tecnologie di virtualizzazione dei processi (i cosidetti
+\textit{container}).
+
+Per far questo l'interfaccia per la creazione di un nuovo processo è stata
+implementata una nuova \textit{system call}, \texttt{sys\_clone}, che consente
+di reimplementare anche la tradizionale \func{fork}. La \textit{system call}
+richiede due argomenti, \param{flags}, che consente di controllare le modalità
+di creazione del nuovo processo e \param{child\_stack}, che deve essere
+indicato se si intende creare un \textit{thread} in cui la memoria viene
+condivisa fra il processo chiamante ed il nuovo processo creato. L'esecuzione
+del programma creato da \param{child\_stack} 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
+processo vede esattamente la stessa memoria del processo chiamante, e nella
+sua esecuzione andrebbe a scrivere sullo \textit{stack} usato anche da questi,
+il che comporterebbe immediatamente la presenza di \itindex{race~condition}
+\textit{race conditions} all'esecuzione di una funzione da parte di entrambi
+(si ricordi quanto visto in sez.~\ref{sec:proc_mem_layout} riguardo all'uso
+dello \textit{stack}). 
+
+Per evitare questo è allora necessario che il chiamante allochi
+preventivamente un'area di memoria (in genere lo si fa con una \func{malloc})
+che la funzione imposterà come \textit{stack} del nuovo processo, avendo
+ovviamente cura di non utilizzarla direttamente. Si tenga presente inoltre che
+in molte architetture 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 con essa allocato. 
+
+Dato che tutto ciò serve 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 il valore \val{NULL}
+per \param{child\_stack}, nel qual caso si applicherà la semantica del
+\itindex{copy-on-write} \textit{copy on write} illustrata in
+sez.~\ref{sec:proc_fork}, le pagine dello \textit{stack} verranno
+automaticamente copiate come le altre e il nuovo processo avrà un suo
+\textit{stack}.
+
+

 
 \subsection{La funzione \func{prctl}}
 \label{sec:process_prctl}
 
 \subsection{La funzione \func{prctl}}
 \label{sec:process_prctl}