From: Simone Piccardi Date: Wed, 2 Nov 2011 18:57:59 +0000 (+0000) Subject: Materiale su clone, inizio X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=commitdiff_plain;h=60e682c9d632073938de25c85bc9a984528d349a Materiale su clone, inizio --- diff --git a/filedir.tex b/filedir.tex index a48b858..88c392e 100644 --- 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 -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 @@ -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 -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 @@ -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}, -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 @@ -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}). - 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{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}. -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)} @@ -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. -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 @@ -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 -``\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 @@ -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 - \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} @@ -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 -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} diff --git a/fileunix.tex b/fileunix.tex index 18fb5d8..5e3a39a 100644 --- 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 - 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 09b2ea5..d3fe9c5 100644 --- 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 - \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 - 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.} diff --git a/prochand.tex b/prochand.tex index 78ad88d..8120b9f 100644 --- 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 - 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 @@ -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 -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. @@ -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 -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] @@ -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 -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} -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}