From b3b4f26462b7f1898aee125226952995270167d7 Mon Sep 17 00:00:00 2001 From: Simone Piccardi Date: Mon, 15 Oct 2001 17:40:18 +0000 Subject: [PATCH] Aggiunte --- gapil.tex | 2 +- prochand.tex | 34 +++++++++---- simpltcp.tex | 138 ++++++++++++++++++++++++++------------------------- 3 files changed, 94 insertions(+), 80 deletions(-) diff --git a/gapil.tex b/gapil.tex index 1883b68..fd60529 100644 --- a/gapil.tex +++ b/gapil.tex @@ -1,7 +1,7 @@ %% %% GaPiL : Guida alla Programmazione in Linux %% -%% S. Piccardi Feb. 2001 +%% S. Piccardi Oct. 2000 %% %% main.tex: file principale, gli altri vanno inclusi da questo. %% diff --git a/prochand.tex b/prochand.tex index 7414968..89f8b98 100644 --- a/prochand.tex +++ b/prochand.tex @@ -1215,17 +1215,29 @@ connesse alla gestione accorta dei privilegi. \subsection{Utente e gruppo di un processo} \label{sec:proc_user_group} -Abbiamo già accennato in \secref{sec:intro_multiuser} che il sistema base -della sicurezza in unix è basato sui concetti di utente e gruppo; ad essi sono -associati due identificatori univoci, lo \acr{uid} e il \acr{gid} che li -contraddistinguono nei confronti del kernel. Questi identificatori sono quelli -che vengono controllati nella gestione di permessi e protezioni in un sistema -unix, e oltre che per il controllo di accesso ai file, già esposto in -\secref{sec:file_access_control}, vengono usati anche nella gestione dei -privilegi di accesso dei processi. - -Abbiamo già incontrato in \secref{sec:file_perm_overview} - +Come abbiamo già accennato in \secref{sec:intro_multiuser} il modello +base\footnote{in realtà esistono estensioni di questo modello, che lo rendono + più flessibile e controllabile, come le \textit{capabilities}, le ACL per i + file o il modello a ``... NdT riprendere i dati'' di SELinux} di sicurezza +di un sistema unix è fondato sui concetti di utente e gruppo, e sulla +separazione fra amministratore (che può fare tutto) e resto degli +utenti. + +%Benché il sistema sia piuttosto semplice il sistema permette una +%notevole fles + +Abbiamo già visto come i\l sistema associ ad ogni utente e gruppo due +identificatori, lo \acr{uid} e il \acr{gid}, che li contraddistinguono e che +sono questi quelli che vengono controllati dal kernel nella gestione di +permessi e protezioni; in \secref{sec:file_access_control} si è visto come +essi vengano utilizzati per il controllo di accesso ai file, vedremo ora come +come sono usati nella gestione dei privilegi di accesso dei processi. + +In \secref{sec:file_perm_overview} abbiamo visto come ogni file appartenga ad +un utente e ad un gruppo, e che il controllo di accesso viene eseguito sulla +base del + +Nel caso dei processi però Ad ogni processo è associato un certo numero di identificatori, il cui elenco diff --git a/simpltcp.tex b/simpltcp.tex index 5b984ae..6183212 100644 --- a/simpltcp.tex +++ b/simpltcp.tex @@ -43,8 +43,8 @@ una implementazione completa. \subsection{La struttura del server} \label{sec:TCPsimp_server_main} -La prima versione del server, \texttt{ElemEchoTCPServer.c}, si compone di un -corpo principale, costituito dalla funzione \texttt{main}. Questa si incarica +La prima versione del server, \file{ElemEchoTCPServer.c}, si compone di un +corpo principale, costituito dalla funzione \func{main}. Questa si incarica di creare il socket, metterlo in ascolto di connessioni in arrivo e creare un processo figlio a cui delegare la gestione di ciascuna connessione. Questa parte, riportata in \nfig, è analoga a quella vista nel precedente esempio @@ -116,19 +116,19 @@ quella dell'esempio citato, ed ad esso si applicano le considerazioni fatte in \secref{sec:TCPel_cunc_daytime}. Le uniche differenze rispetto all'esempio in \figref{fig:TCPel_serv_code} sono che in questo caso per il socket in ascolto viene usata la porta 7 e tutta la gestione della comunicazione è -delegata alla funzione \texttt{ServEcho}. +delegata alla funzione \func{ServEcho}. % Per ogni connessione viene creato un % processo figlio, il quale si incarica di lanciare la funzione % \texttt{SockEcho}. -Il codice della funzione \texttt{ServEcho} è invece mostrata in \nfig, la +Il codice della funzione \func{ServEcho} è invece mostrata in \nfig, la comunicazione viene gestita all'interno del ciclo (linee \texttt{\small 6--8}). I dati inviati dal client vengono letti dal socket con una semplice \texttt{read} (che ritorna solo in presenza di dati in arrivo), la riscrittura -viene invece gestita dalla funzione \texttt{SockWrite} (descritta a suo tempo +viene invece gestita dalla funzione \func{SockWrite} (descritta a suo tempo in \figref{fig:sock_SockWrite_code}) che si incarica di tenere conto automaticamente della possibilità che non tutti i dati di cui è richiesta la -scrittura vengano trasmessi con una singola \texttt{write}. +scrittura vengano trasmessi con una singola \func{write}. \begin{figure}[!htb] @@ -151,7 +151,7 @@ void ServEcho(int sockfd) { \end{figure} Quando il client chiude la connessione il ricevimento del FIN fa ritornare la -\texttt{read} con un numero di byte letti pari a zero, il che causa l'uscita +\func{read} con un numero di byte letti pari a zero, il che causa l'uscita dal ciclo e il ritorno della funzione, che a sua volta causa la terminazione del processo figlio. @@ -204,16 +204,16 @@ int main(int argc, char *argv[]) \label{fig:TCPsimpl_client_elem} \end{figure} -La funzione \texttt{main} si occupa della creazione del socket e della +La funzione \func{main} si occupa della creazione del socket e della connessione (linee \texttt{\small 10--27}) secondo la stessa modalità spiegata in \secref{sec:net_cli_sample}, il client si connette sulla porta 7 all'indirizzo specificato dalla linea di comando (a cui si è aggiunta una elementare gestione delle opzioni non riportata in figura). -Completata la connessione (quando la funzione \texttt{connect} ritorna) la -funzione \texttt{ClientEcho}, riportata in \nfig, si preoccupa di gestire la -comunicazione, leggendo una riga alla volta dallo \texttt{stdin}, scrivendola -sul socket e ristampando su \texttt{stdout} quanto ricevuto in risposta dal +Completata la connessione (quando la funzione \func{connect} ritorna) la +funzione \func{ClientEcho}, riportata in \nfig, si preoccupa di gestire la +comunicazione, leggendo una riga alla volta dallo \file{stdin}, scrivendola +sul socket e ristampando su \file{stdout} quanto ricevuto in risposta dal server. \begin{figure}[!htb] @@ -240,19 +240,19 @@ void ClientEcho(FILE * filein, int socket) La funzione utilizza due buffer per gestire i dati inviati e letti sul socket (\texttt{\small 3}). La comunicazione viene gestita all'interno di un ciclo (linee \texttt{\small 5--10}), i dati da inviare sulla connessione vengono -presi dallo \texttt{stdin} usando la funzione \texttt{fgets} che legge una +presi dallo \texttt{stdin} usando la funzione \func{fgets} che legge una linea di testo (terminata da un \texttt{CR} e fino al massimo di \texttt{MAXLINE} caratteri) e la salva sul buffer di invio, la funzione -\texttt{SockWrite} (\texttt{\small 3}) scrive detti dati sul socket (gestendo -l'invio multiplo qualora una singola \texttt{write} non basti, come spiegato +\func{SockWrite} (\texttt{\small 3}) scrive detti dati sul socket (gestendo +l'invio multiplo qualora una singola \func{write} non basti, come spiegato in \secref{sec:sock_io_behav}). -I dati che vengono riletti indietro con una \texttt{SockRead} sul buffer di +I dati che vengono riletti indietro con una \func{SockRead} sul buffer di ricezione e viene inserita la terminazione della stringa (\texttt{\small - 7--8}) e per poter usare la funzione \texttt{fputs} per scriverli su -\texttt{stdout}. + 7--8}) e per poter usare la funzione \func{fputs} per scriverli su +\file{stdout}. -Un end of file inviato su \texttt{stdin} causa il ritorno di \texttt{fgets} +Un end of file inviato su \file{stdin} causa il ritorno di \func{fgets} con un puntatore nullo e l'uscita dal ciclo, al che la subroutine ritorna ed il client esce. @@ -262,10 +262,10 @@ il client esce. Benché il codice dell'esempio precedente sia molto ridotto, esso ci permetterà di considerare in dettaglio tutte le problematiche che si possono incontrare -nello scrivere una applicazione di rete; infatti attraverso l'esame delle sue +nello scrivere una applicazione di rete. Infatti attraverso l'esame delle sue modalità di funzionamento normali, all'avvio e alla terminazione, e di quello -che avviene nelle varie situazioni limite da una parte potremo approfondire la -comprensione del protocollo TCP/IP e dall'altra ricavare le indicazioni +che avviene nelle varie situazioni limite, da una parte potremo approfondire +la comprensione del protocollo TCP/IP e dall'altra ricavare le indicazioni necessarie per essere in gradi di scrivere applicazioni robuste, in grado di gestire anche i casi limite. @@ -275,9 +275,9 @@ gestire anche i casi limite. Il primo passo è compilare e lanciare il server (da root, per poter usare la porta 7 che è riservata), alla partenza esso eseguirà l'apertura passiva con -la sequenza delle chiamate a \texttt{socket}, \texttt{bind}, \texttt{listen} e -poi si bloccherà nella \texttt{accept}. A questo punto si potrà controllarne -lo stato con \texttt{netstat}: +la sequenza delle chiamate a \func{socket}, \func{bind}, \func{listen} e poi +si bloccherà nella \func{accept}. A questo punto si potrà controllarne lo +stato con \cmd{netstat}: \begin{verbatim} [piccardi@roke piccardi]$ netstat -at Active Internet connections (servers and established) @@ -290,15 +290,15 @@ che ci mostra come il socket sia in ascolto sulla porta richiesta, accettando connessioni da qualunque indirizzo e da qualunque porta e su qualunque interfaccia locale. -A questo punto si può lanciare il client, esso chiamerà \texttt{socket} e -\texttt{connect}, una volta completato il three way handshake la connessione è -stabilita; la \texttt{connect} ritornerà nel client\footnote{si noti che è - sempre la \texttt{connect} del client a ritornare per prima, in quanto +A questo punto si può lanciare il client, esso chiamerà \func{socket} e +\func{connect}; una volta completato il three way handshake la connessione è +stabilita; la \func{connect} ritornerà nel client\footnote{si noti che è + sempre la \func{connect} del client a ritornare per prima, in quanto questo avviene alla ricezione del secondo segmento (l'ACK del server) del - three way handshake, la \texttt{accept} del server ritorna solo dopo + three way handshake, la \func{accept} del server ritorna solo dopo un altro mezzo RTT quando il terzo segmento (l'ACK del client) viene - ricevuto.} e la \texttt{accept} nel server, ed usando di nuovo -\texttt{netstat} otterremmo che: + ricevuto.} e la \func{accept} nel server, ed usando di nuovo +\cmd{netstat} otterremmo che: \begin{verbatim} Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State @@ -307,16 +307,16 @@ tcp 0 0 roke:echo gont:32981 ESTABLISHED \end{verbatim} mentre per quanto riguarda l'esecuzione dei programmi avremo che: \begin{itemize} -\item il client chiama la funzione \texttt{ClientEcho} che si blocca sulla - \texttt{fgets} dato che non si è ancora scritto nulla sul terminale. -\item il server eseguirà una \texttt{fork} facendo chiamare al processo figlio - la funzione \texttt{ServEcho}, quest'ultima si bloccherà sulla \texttt{read} +\item il client chiama la funzione \func{ClientEcho} che si blocca sulla + \func{fgets} dato che non si è ancora scritto nulla sul terminale. +\item il server eseguirà una \func{fork} facendo chiamare al processo figlio + la funzione \func{ServEcho}, quest'ultima si bloccherà sulla \func{read} dal socket sul quale ancora non sono presenti dati. -\item il processo padre del server chiamerà di nuovo \texttt{accept} +\item il processo padre del server chiamerà di nuovo \func{accept} bloccandosi fino all'arrivo di un'altra connessione. \end{itemize} -e se usiamo il comando \texttt{ps} per esaminare lo stato dei processi -otterremo un risultato del tipo: +e se usiamo il comando \ps{ps} per esaminare lo stato dei processi otterremo +un risultato del tipo: \begin{verbatim} [piccardi@roke piccardi]$ ps ax PID TTY STAT TIME COMMAND @@ -330,7 +330,7 @@ tre processi, tutti in stato di \textit{sleep} (S). Se a questo punto si inizia a scrivere qualcosa sul client niente sarà trasmesso fin tanto che non si prema il ritorno carrello, allora la -\texttt{fgets} ritornerà e a questo punto il client scriverà quanto immesso +\func{fgets} ritornerà e a questo punto il client scriverà quanto immesso sul socket, poi rileggerà quanto gli viene inviato all'indietro dal server, e questo sarà inviato sullo standard output, che nel caso ne provoca l'immediatamente stampa a video. @@ -350,40 +350,40 @@ Ho finito Ho finito \end{verbatim} %$ che termineremo inviando un EOF dal terminale (usando la combinazione di tasti -ctrl-D, che non compare a schermo); se eseguiamo un \texttt{netstat} a questo +ctrl-D, che non compare a schermo); se eseguiamo un \cmd{netstat} a questo punto avremo: \begin{verbatim} [piccardi@roke piccardi]$ netstat -at tcp 0 0 *:echo *:* LISTEN tcp 0 0 localhost:33032 localhost:echo TIME_WAIT \end{verbatim} %$ -con il client che entra in \texttt{TIME\_WAIT}. +con il client che entra in \macro{TIME\_WAIT}. Esaminiamo allora in dettaglio la sequenza di eventi che porta alla terminazione normale della connessione, che ci servirà poi da riferimento nei casi seguenti: \begin{enumerate} -\item inviando un carattere di EOF da terminale la \texttt{fgets} ritorna +\item inviando un carattere di EOF da terminale la \func{fgets} ritorna restituendo un puntatore nullo che causa l'uscita dal ciclo di - \texttt{while}, così la \texttt{ClientEcho} ritorna. -\item al ritorno di \texttt{ClientEcho} ritorna anche la funzione - \texttt{main}, e come parte del processo terminazione tutti i file - descriptor vengono chiusi (si ricordi quanto visto in - \secref{sec:proc_term_conclusion}), il che causa la chiusura del socket di - comunicazione; il client allora invierà un FIN al server a cui questo - risponderà con un ACK. A questo punto il client verrà a trovarsi nello - stato \texttt{FIN\_WAIT\_2} ed il server nello stato \texttt{CLOSE\_WAIT} - (si riveda quanto spiegato in \secref{sec:TCPel_conn_term}). -\item quando il server riceve il FIN la la \texttt{read} del processo figlio - che gestisce la connessione ritorna restituendo 0 causando così l'uscita dal - ciclo di \texttt{while} e il ritorno di \texttt{ServEcho}, a questo punto il - processo figlio termina chiamando \texttt{exit}. + while, così la \func{ClientEcho} ritorna. +\item al ritorno di \func{ClientEcho} ritorna anche la funzione \func{main}, e + come parte del processo terminazione tutti i file descriptor vengono chiusi + (si ricordi quanto detto in \secref{sec:proc_term_conclusion}); questo causa + la chiusura del socket di comunicazione; il client allora invierà un FIN al + server a cui questo risponderà con un ACK. A questo punto il client verrà a + trovarsi nello stato \macro{FIN\_WAIT\_2} ed il server nello stato + \macro{CLOSE\_WAIT} (si riveda quanto spiegato in + \secref{sec:TCPel_conn_term}). +\item quando il server riceve il FIN la \func{read} del processo figlio che + gestisce la connessione ritorna restituendo 0 causando così l'uscita dal + ciclo di while e il ritorno di \func{ServEcho}, a questo punto il processo + figlio termina chiamando \func{exit}. \item all'uscita del figlio tutti i file descriptor vengono chiusi, la chiusura del socket connesso fa sì che venga effettuata la sequenza finale di chiusura della connessione, viene emesso un FIN dal server che riceverà un ACK dal client, a questo punto la connessione è conclusa e il client - resta nello stato \texttt{TIME\_WAIT}. + resta nello stato \func{TIME\_WAIT}. \item \end{enumerate} @@ -391,21 +391,23 @@ casi seguenti: \subsection{La gestione dei processi figli} \label{sec:TCPsimpl_child_hand} -Tutto questo riguarda la connessione, c'è però un'altro effetto del -procedimento di chiusura del processo figlio nel server, e cioè l'invio del -segnale \texttt{SIGCHILD} al padre. Dato che non si è installato un -manipolatore (vedi \secref{cha:signals} per le problematiche relative) e che -l'azione di default per questo segnale è quella di essere ignorato quello che -avremo è che il processo figlio entrerà nello stato di zombie, come risulta -una volta che ripetiamo il comando \texttt{ps}: +Tutto questo riguarda la connessione, c'è però da tenere conto dell'effetto +del procedimento di chiusura del processo figlio nel server (si veda quanto +esaminato in \secref{sec:proc_termination}). In questo caso avremo l'invio del +segnale \macro{SIGCHILD} al padre, ma dato che non si è installato un +manipolatore e che l'azione di default per questo segnale è quella di essere +ignorato, non avendo predisposto la ricezione dello stato di terminazione, +otterremo che il processo figlio entrerà nello stato di zombie, come risulterà +ripetendo il comando \cmd{ps}: \begin{verbatim} 2356 pts/0 S 0:00 ./echod 2359 pts/0 Z 0:00 [echod ] \end{verbatim} -Poiché non è possibile lasciare processi zombie (che pur inattivi occupano +Poiché non è possibile lasciare processi zombie che pur inattivi occupano spazio nella tabella dei processi e a lungo andare saturerebbero le risorse -del kernel occorrerà gestire il segnale, per questo installeremo un -manipolatore usando la funzione \texttt{Signal} (trattata in dettaglio in -\secref{sec:sig_signal}). +del kernel, occorrerà ricevere opportunamente lo stato di terminazione del +processo (si veda \secref{sec:proc_wait}), cosa che faremo utilizzando il +segnale, per questo installeremo un manipolatore usando la funzione +\func{Signal} (trattata in dettaglio in \secref{sec:sig_signal}). -- 2.30.2