\textsl{finestra annunciata} (\textit{advertized window}) con la quale
ciascun capo della comunicazione dichiara quanto spazio disponibile ha in
memoria per i dati. Questo è un numero a 16 bit dell'header, che così può
- indicare un massimo di 65535 bytes (anche se Linux usa come massimo 32767
+ indicare un massimo di 65535 byte (anche se Linux usa come massimo 32767
per evitare problemi con alcuni stack bacati che usano l'aritmetica con
segno per implementare lo stack TCP); ma alcuni tipi di connessione come
quelle ad alta velocità (sopra i 45Mbits/sec) e quelle che hanno grandi
eseguire la chiusura passiva a quello che sta eseguendo la chiusura attiva.
Nella sequenza indicata i dati verrebbero persi, dato che si è chiuso il
socket dal lato che esegue la chiusura attiva; esistono tuttavia situazioni in
-cui si vuole poter sfuttare questa possibilità, usando una procedura che è
+cui si vuole poter sfruttare questa possibilità, usando una procedura che è
chiamata \textit{half-close}; torneremo su questo aspetto e su come
utilizzarlo più avanti, quando parleremo della funzione \func{shutdown}.
\end{figure}
La connessione viene iniziata dal client che annuncia un MSS di 1460 (un
-valore tipico per IPv4 su ethernet) con Linux, il server risponde con lo
+valore tipico per IPv4 su Ethernet) con Linux, il server risponde con lo
stesso valore (ma potrebbe essere anche un valore diverso).
Una volta che la connessione è stabilita il client scrive al server una
richiesta (che assumiamo stare in un singolo segmento, cioè essere minore dei
-1460 bytes annunciati dal server), quest'ultimo riceve la richiesta e
+1460 byte annunciati dal server), quest'ultimo riceve la richiesta e
restituisce una risposta (che di nuovo supponiamo stare in un singolo
segmento). Si noti che l'acknowledge della richiesta è mandato insieme alla
risposta, questo viene chiamato \textit{piggybacking} ed avviene tutte le
operazione.
\item \macro{EAGAIN} o \macro{EWOULDBLOCK} il socket è stato settato come
non bloccante, e non ci sono connessioni in attesa di essere accettate.
- \item \macro{EFAULT} l'argomento \var{addr} .
- \item \macro{EPERM} Firewall rules forbid connection.
-
- \item \macro{ENOBUFS, ENOMEM} Not enough free memory. This often means
- that the memory allocation is limited by the socket buffer limits, not by
- the system memory.
-
- Inoltre possono essere restituiti gli errori di rete relativi al nuovo
- socket come: \macro{EMFILE}, \macro{EINVAL}, \macro{ENOSR},
- \macro{ENOBUFS}, \macro{EPERM}, \macro{ECONNABORTED},
- \macro{ESOCKTNOSUPPORT}, \macro{EPROTONOSUPPORT}, \macro{ETIMEDOUT},
- \macro{ERESTARTSYS}.
-
+ \item \macro{EPERM} Le regole del firewall non consentono la connessione.
+ \item \macro{ENOBUFS, ENOMEM} . Questo spesso significa che l'allocazione
+ della memoria è limitata dai limiti sui buffer dei socket, non dalla
+ memoria di sistema.
\end{errlist}
+ Inoltre possono essere restituiti gli errori di rete relativi al nuovo
+ socket come: \macro{EMFILE}, \macro{EINVAL}, \macro{ENOSR}, \macro{ENOBUFS},
+ \macro{EFAULT}, \macro{EPERM}, \macro{ECONNABORTED},
+ \macro{ESOCKTNOSUPPORT}, \macro{EPROTONOSUPPORT}, \macro{ETIMEDOUT},
+ \macro{ERESTARTSYS}.
\end{prototype}
La funzione può essere usata solo con socket che supportino la connessione
esplicita della connessione, (attualmente in Linux solo DECnet ha questo
comportamento), la funzione opera solo l'estrazione dalla coda delle
connessioni, la conferma della connessione viene fatta implicitamente dalla
-prima chiamata ad una \func{read} o una \func{write} mentre il rifiuto
-della connessione viene fatto con la funzione \func{close}.
+prima chiamata ad una \func{read} o una \func{write} mentre il rifiuto della
+connessione viene fatto con la funzione \func{close}.
È da chiarire che Linux presenta un comportamento diverso nella gestione degli
errori rispetto ad altre implementazioni dei socket BSD, infatti la funzione
l'indirizzo del client da cui proviene la connessione. Prima della chiamata
\var{addrlen} deve essere inizializzato alle dimensioni della struttura il
cui indirizzo è passato come argomento in \var{cliaddr}, al ritorno della
-funzione \var{addrlen} conterrà il numero di bytes scritti dentro
+funzione \var{addrlen} conterrà il numero di byte scritti dentro
\var{cliaddr}. Se questa informazione non interessa basterà inizializzare a
\macro{NULL} detti puntatori.
questo avviene quando il server invece di far gestire la connessione
direttamente a un processo figlio, come nell'esempio precedente, lancia un
opportuno programma per ciascuna connessione usando \func{exec} (questa ad
-esempio è la modailità con cui opera il \textsl{super-server} \cmd{inetd}
+esempio è la modalità con cui opera il \textsl{super-server} \cmd{inetd}
che gestisce tutta una serie di servizi lanciando per ogni connessione
l'opportuno server).
che non è un \textit{block device} in un contesto in cui era necessario
specificare un \textit{block device} (ad esempio si è tentato di montare un
file ordinario).
-\item \macro{EEXIST} \textit{File exists}. Si è specficato un file esistente
- in un constesto in cui ha senso solo specificare un nuovo file.
+\item \macro{EEXIST} \textit{File exists}. Si è specificato un file esistente
+ in un contesto in cui ha senso solo specificare un nuovo file.
\item \macro{EBUSY} \textit{Resource busy}. Una risorsa di sistema che non può
essere condivisa è occupata. Ad esempio si è tentato di cancellare la
- directory su cui si è montato un filesistem.
+ directory su cui si è montato un filesystem.
\item \macro{EXDEV} \textit{Cross-device link}. Si è tentato di creare un link
diretto che attraversa due filesystem differenti.
\item \macro{ENODEV} \textit{No such device}. Si è indicato un tipo di device
filesystem NFS.
\item \macro{EREMOTE} \textit{Object is remote}. Si è fatto un tentativo di
montare via NFS un filesystem remoto con un nome che già specifica un
- filesystem montao via NFS.
+ filesystem montato via NFS.
\item \macro{ENOLCK} \textit{No locks available}. È usato dalle utilità per la
gestione del file lock; non viene generato da un sistema GNU, ma può
risultare da un'operazione su un server NFS di un altro sistema.
sbagliato per il socket. Il socket usato non supporta il protocollo di
comunicazione richiesto.
\item \macro{ENOPROTOOPT} \textit{Protocol not available}. Protocollo non
- disponibile. Si è richiesta un'opzione per il socket non diponibile con il
+ disponibile. Si è richiesta un'opzione per il socket non disponibile con il
protocollo usato.
\item \macro{EPROTONOSUPPORT} \textit{Protocol not supported}. Protocollo non
supportato. Il tipo di socket non supporta il protocollo richiesto (un
\item \macro{ESOCKTNOSUPPORT} \textit{Socket type not supported}. Socket non
supportato. Il tipo di socket scelto non è supportato.
\item \macro{EOPNOTSUPP} \textit{Operation not supported on transport
- endpoint}. L'operazione richesta non è supportata. Alcune funzioni non
+ endpoint}. L'operazione richiesta non è supportata. Alcune funzioni non
hanno senso per tutti i tipi di socket, ed altre non sono implementate per
tutti i protocolli di trasmissione. Questo errore quando un socket non
supporta una particolare operazione, e costituisce una indicazione generica
\item \macro{ECONNREFUSED} \textit{Connection refused}. Un host remoto ha
rifiutato la connessione (in genere dipende dal fatto che non c'è un server
per soddisfare il servizio richiesto).
-\item \macro{EHOSTDOWN} \textit{Host is down}. L'host remorto di una
+\item \macro{EHOSTDOWN} \textit{Host is down}. L'host remoto di una
connessione è giù.
-\item \macro{EHOSTUNREACH} \textit{No route to host}. L'host remorto di una
+\item \macro{EHOSTUNREACH} \textit{No route to host}. L'host remoto di una
connessione non è raggiungibile.
\end{description}
\section{Errori generici}
In questa sezione sono raccolti i codici restituiti dalle funzioni di libreria
-attinenti ad errori generici, si trovano qui tutti i cosici di errore non
+attinenti ad errori generici, si trovano qui tutti i codici di errore non
specificati nelle sezioni precedenti.
\begin{description}
queste situazioni, nel qual caso si avrebbe in blocco.
\item \macro{EFAULT} \textit{Bad address}. Una stringa passata come parametro
è fuori dello spazio di indirizzi del processo, in genere questa situazione
- provoca l'emissione di un sengale di \textit{segment violation}
+ provoca l'emissione di un segnale di \textit{segment violation}
(\macro{SIGSEGV}).
\item \macro{EINVAL} \textit{Invalid argument}. Errore utilizzato per
segnalare vari tipi di problemi dovuti all'aver passato un argomento
Una caratteristica comune a diversi sistemi operativi è quella di poter creare
dei nomi fittizi (come gli alias del MacOS o i collegamenti di Windows) che
-permettono di fare riferiremento allo stesso file chiamandolo con nomi diversi
+permettono di fare riferimento allo stesso file chiamandolo con nomi diversi
o accedendovi da directory diverse.
Questo è possibile anche in ambiente unix, dove tali collegamenti sono
Per quanto dicevamo in \secref{sec:file_filesystem} la creazione di un
collegamento diretto è possibile solo se entrambi i pathname sono nello stesso
filesystem; inoltre il filesystem deve supportare i collegamenti diretti (il
-mneccanismo non è disponibile ad esempio con il filesystem \acr{vfat} di
+meccanismo non è disponibile ad esempio con il filesystem \acr{vfat} di
Windows).
La funzione inoltre opera sia sui file ordinari che sugli altri oggetti del
\begin{prototype}{stdio.h}
{int rename(const char *oldpath, const char *newpath)}
- Rinomina \var{oldpath} in \var{newpth}, eseguendo se necessario lo
+ Rinomina \var{oldpath} in \var{newpath}, eseguendo se necessario lo
spostamento di un file fra directory diverse. Eventuali altri link diretti
allo stesso file non vengono influenzati.
Come abbiamo visto in \secref{sec:file_link} la funzione \func{link} crea
riferimenti agli inodes, pertanto può funzionare soltanto per file che
-risiedono sullo stesso filesysteme e solo per un filesystem di tipo unix.
+risiedono sullo stesso filesystem e solo per un filesystem di tipo unix.
Inoltre abbiamo visto che in Linux non è consentito eseguire un link diretto
ad una directory.
\item \macro{EMLINK} La directory in cui si vuole creare la nuova directory
contiene troppi file. Sotto Linux questo normalmente non avviene perché il
filesystem standard consente la creazione di un numero di file maggiore di
- quelli che possono essere contenuti nell'hard-disk, ma potendo avere a che
+ quelli che possono essere contenuti nel disco, ma potendo avere a che
fare anche con filesystem di altri sistemi questo errore può presentarsi.
\item \macro{ENOSPC} Non c'è abbastanza spazio sul file system per creare
la nuova directory o si è esaurita la quota disco dell'utente.
Il buffer deve essere sufficientemente lungo da poter contenere il pathname
completo più lo zero di terminazione della stringa. Qualora esso ecceda le
-dimensioni specificate con \var{size} la funzione restituiece un errore. Si
+dimensioni specificate con \var{size} la funzione restituisce un errore. Si
può anche specificare un puntatore nullo come \var{buffer}\footnote{questa è
una estensione allo standard POSIX.1, supportata da Linux}, nel qual caso la
stringa sarà allocata automaticamente per una dimensione pari a \var{size}
Se però il file del programma\footnote{per motivi di sicurezza il kernel
ignora i bit \acr{suid} e \acr{sgid} per gli script eseguibili} (che
ovviamente deve essere eseguibile) ha il bit \acr{suid} settato, il kernel
-assegnerà come \textit{effective user id} al nuovo processo l'uid del
-proprietario del file al posto dell'uid del processo originario. Avere il bit
-\acr{sgid} settato ha lo stesso effetto sull'\textit{effective group id} del
-processo.
-
-I bit \acr{suid} e \acr{sgid} vengono usati per permettere agli utenti
-normali di usare programmi che abbisognano di privilegi speciali; l'esempio
-classico è il comando \cmd{passwd} che ha la necessità di modificare il file
-delle password, quest'ultimo ovviamente può essere scritto solo
-dall'amministratore, ma non è necessario chiamare l'amministratore per
-cambiare la propria password. Infatti il comando \cmd{passwd} appartiene a
-root ma ha il bit suid settato per cui quando viene lanciato da un utente
-normale parte con i privilegi di root.
+assegnerà come \textit{effective user id} al nuovo processo l'\acr{uid} del
+proprietario del file al posto dell'\acr{uid} del processo originario. Avere
+il bit \acr{sgid} settato ha lo stesso effetto sull'\textit{effective group
+ id} del processo.
+
+I bit \acr{suid} e \acr{sgid} vengono usati per permettere agli utenti normali
+di usare programmi che abbisognano di privilegi speciali; l'esempio classico è
+il comando \cmd{passwd} che ha la necessità di modificare il file delle
+password, quest'ultimo ovviamente può essere scritto solo dall'amministratore,
+ma non è necessario chiamare l'amministratore per cambiare la propria
+password. Infatti il comando \cmd{passwd} appartiene a root ma ha il bit
+\acr{suid} settato per cui quando viene lanciato da un utente normale parte
+con i privilegi di root.
Chiaramente avere un processo che ha privilegi superiori a quelli che avrebbe
normalmente l'utente che lo ha lanciato comporta vari rischi, e questo tipo di
\begin{itemize}
\item il \acr{gid} del file corrisponde all'\textit{effective group id} del
processo.
-\item il \acr{gid} del file corrisponde al gid della directory in cui esso è
- creato.
+\item il \acr{gid} del file corrisponde al \acr{gid} della directory in cui
+ esso è creato.
\end{itemize}
in genere BSD usa sempre la seconda possibilità, che viene per questo chiamata
-semantica BSD. Linux invece segue quella che viene chiamata semantica SVR4; di
+semantica BSD. Linux invece segue quella che viene chiamata semantica SVr4; di
norma cioè il nuovo file viene creato, seguendo la prima opzione, con il
\acr{gid} del processo, se però la directory in cui viene creato il file ha il
bit \acr{sgid} settato allora viene usata la seconda opzione.
nuovi file (lettura e scrittura per il proprietario, sola lettura per il
gruppo e gli altri) sono corrispondenti al valore ottale $0644$, un programma
invece avrebbe anche il bit di esecuzione attivo, con un valore di $0755$, se
-si volesse attivare il bit suid il valore da fornire sarebbe $4755$.
+si volesse attivare il bit \acr{suid} il valore da fornire sarebbe $4755$.
\begin{table}[!htb]
\centering
bufferizzato in quanto la lettura e la scrittura vengono eseguite chiamando
direttamente le system call del kernel (in realtà il kernel effettua al suo
interno alcune bufferizzazioni per aumentare l'efficienza nell'accesso ai
-dispositivi); i file descriptors sono rappresentati da numeri interi (cioè
+dispositivi); i file descriptor sono rappresentati da numeri interi (cioè
semplici variabili di tipo \type{int}). L'interfaccia è definita
nell'header \file{unistd.h}.
Entrambe le interfacce possono essere usate per l'accesso ai file come agli
altri oggetti del VFS (pipe, socket, device), ma per poter accedere alle
operazioni di controllo sul particolare tipo di oggetto del VFS scelto occorre
-usare l'interfaccia standard di unix coi file descriptors. Allo stesso modo
+usare l'interfaccia standard di unix coi file descriptor. Allo stesso modo
devono essere usati i file descriptor se si vuole ricorrere a modalità
speciali di I/O come il polling o il non-bloccante (vedi
\secref{sec:file_noblocking}).
una apposita struttura che contiene vari dati come le informazioni comuni ad
ogni filesystem, i dati privati relativi a quel filesystem specifico, e i
puntatori alle funzioni del kernel relative al filesystem. Il VFS può così
-usare le funzioni contenute nel filesystem decriptor per accedere alle routine
+usare le funzioni contenute nel filesystem descriptor per accedere alle routine
specifiche di quel filesystem.
Gli altri due descrittori usati dal VFS sono relativi agli altri due oggetti
kernel quando agisce su gruppi di file. Possono essere settati su file e
directory e in quest'ultimo caso i nuovi file creati nella directory
ereditano i suoi attributi.
-\item sono supportate entrambe le semantiche di BSD e SYSV come opzioni di
+\item sono supportate entrambe le semantiche di BSD e SVr4 come opzioni di
montaggio. La semantica BSD comporta che i file in una directory sono creati
con lo stesso identificatore di gruppo della directory che li contiene. La
- semantica SYSV comporta che i file vengono creati con l'identificatore del
+ semantica SVr4 comporta che i file vengono creati con l'identificatore del
gruppo primario del processo, eccetto il caso in cui la directory ha il bit
di \acr{sgid} settato (per una descrizione dettagliata del significato di
questi termini si veda \secref{sec:file_access_control}), nel qual caso file
- e sotto-directory ereditano sia il \acr{gid} che lo \acr{sgid}.
+ e subdirectory ereditano sia il \acr{gid} che lo \acr{sgid}.
\item l'amministratore può scegliere la dimensione dei blocchi del filesystem
in fase di creazione, a seconda delle sue esigenze (blocchi più grandi
permettono un accesso più veloce, ma sprecano più spazio disco).
\label{fig:file_ext2_dirs}
\end{figure}
-L'utilizzo di raggrupamenti di blocchi ha inoltre degli effetti positivi nelle
+L'utilizzo di raggruppamenti di blocchi ha inoltre degli effetti positivi nelle
prestazioni dato che viene ridotta la distanza fra i dati e la tabella degli
inode.
stream, come la posizione corrente, lo stato del buffer e degli indicatori di
stato e di fine del file. Per questo motivo gli utenti non devono mai
utilizzare direttamente o allocare queste strutture, ma usare sempre puntatori
-del tipo \type{FILE *} (tanto che in certi caso il termine di puntatore a file
+del tipo \type{FILE *} (tanto che in certi casi il termine di puntatore a file
è diventato sinonimo di stream).
\subsection{Gli stream standard}
\subsection{La bufferizzazione}
\label{sec:file_buffering}
+
+
\section{Funzioni base}
\label{sec:file_ansi_base_func}
+
\subsection{Apertura di uno stream}
\label{sec:file_fopen}
+
\subsection{Lettura e scrittura su uno stream}
\label{sec:file_io}
+
\subsection{Posizionamento su uno stream}
\label{sec:file_fseek}
+
\subsection{Input/output binario}
\label{sec:file_binary_io}
+
\subsection{Input/output di linea}
\label{sec:file_line_io}
+
\subsection{Input/output formattato}
\label{sec:file_formatted_io}
+
\subsection{Chiusura di uno stream}
\label{sec:file_fclose}
+
+
\section{Funzioni avanzate}
\label{sec:file_stream_adv_func}
\subsection{Dettagli dell'implementazione}
\label{sec:file_stream_details}
+
\subsection{File temporanei}
\label{sec:file_temp_file}
+
\subsection{Efficienza}
\label{sec:file_stream_efficiency}
\macro{SIGURG} per gli eventi associati al file descriptor \var{fd}. Il
process group è restituito come valore negativo.
\item[\macro{F\_SETOWN}] setta il processo o process group che riceverà i
- sengali \macro{SIGIO} e \macro{SIGURG} per gli eventi associati al file
+ segnali \macro{SIGIO} e \macro{SIGURG} per gli eventi associati al file
descriptor \var{fd}. I process group sono settati usando valori negativi.
\item[\macro{F\_GETSIG}] restituisce il segnale mandato quando ci sono dati
disponibili in input sul file descriptor. Il valore 0 indica il default (che
l'informazione necessaria al dispositivo.
La funzione nella maggior parte dei casi ritorna 0, alcune operazioni usano
- però il valore di ritorno per restituire informazoni. In caso di errore
+ però il valore di ritorno per restituire informazioni. In caso di errore
viene sempre restituito -1 e \var{errno} viene settata ad uno dei valori
seguenti:
\begin{errlist}
\chapter{Il protocollo IP}
\label{cha:ip_protocol}
-L'attuale Internent Protocol (IPv4) viene standardizzato nel 1981
+L'attuale Internet Protocol (IPv4) viene standardizzato nel 1981
dall'RFC~719; esso nasce per disaccoppiare le applicazioni della struttura
hardware delle reti di trasmissione, e creare una interfaccia di trasmissione
dei dati indipendente dal sottostante substrato di rete, che può essere
In realtà il problema non è propriamente legato al numero di indirizzi
disponibili; infatti con 32 bit si hanno $2^{32}$, cioè circa 4 miliardi,
-numeri diversi possibili, che sono molti di più dei computer attualemente
+numeri diversi possibili, che sono molti di più dei computer attualmente
esistenti.
Il punto è che la suddivisione di questi numeri nei due livelli rete/host e
\textsl{etichetta di flusso}, vedi Sez.~\ref{sec:IP_ipv6_flow}\\
\textit{payload leght} & 16 bit &
\textsl{lunghezza del carico}, cioè del corpo dei dati che segue
- l'intestazione, in bytes. \\
+ l'intestazione, in byte. \\
\textit{next header} & 8 bit & \textsl{testata successiva},
identifica il tipo di pacchetto che segue la testata di IPv6, usa gli
stessi valori del campo protocollo nella testata di IPv4\\
necessità di ricalcolare la checksum ad ogni passaggio di un pacchetto per
il cambiamento del campo \textit{hop limit}.
\item è stato eliminato il campo \textit{type of service}, che praticamente
- non è mai stato utilizzato; una parte delle funzionalià ad esso delegate
+ non è mai stato utilizzato; una parte delle funzionalità ad esso delegate
sono state reimplementate (vedi il campo \textit{priority} al prossimo
punto) con altri metodi.
\item è stato introdotto un nuovo campo \textit{flow label}, che viene usato,
\item IPv6 richiede il supporto per il \textit{path MTU discovery} (cioè il
protocollo per la selezione della massima lunghezza del pacchetto); seppure
questo sia in teoria opzionale, senza di esso non sarà possibile inviare
- pacchetti più larghi della dimensione minima (576 bytes).
+ pacchetti più larghi della dimensione minima (576 byte).
\end{itemize}
\section{Gli indirizzi di IPv6}
lasciano normalmente gli ultimi 64~bit a disposizione per questo livello, la
modalità più immediata è quella di usare uno schema del tipo mostrato in
\tabref{tab:IP_ipv6_uninterf} dove l'\textit{Interface Id} è dato dal
-MAC-address a 48~bit dello standard ethernet, scritto in genere nell'hardware
+MAC-address a 48~bit dello standard Ethernet, scritto in genere nell'hardware
delle scheda di rete, e si usano i restanti 16~bit per indicare la sottorete.
\begin{table}[htb]
Per aumentare la velocità di processo, sia dei dati del livello seguente che
di ulteriori opzioni, ciascuna estensione deve avere una lunghezza multipla di
-8 bytes per mantenere l'allineamento a 64~bit di tutti le testate seguenti.
+8 byte per mantenere l'allineamento a 64~bit di tutti le testate seguenti.
Dato che la maggior parte di queste estensioni non sono esaminate dai router
durante l'instradamento e la trasmissione dei pacchetti, ma solo all'arrivo
di tutte quante.
Un secondo miglioramento è che rispetto a IPv4 le opzioni possono essere di
-lunghezza arbitraria e non limitate a 40 bytes; questo, insieme al modo in cui
+lunghezza arbitraria e non limitate a 40 byte; questo, insieme al modo in cui
vengono trattate, consente di utilizzarle per scopi come l'autenticazione e la
sicurezza, improponibili con IPv4.
Con IPv4 non è possibile realizzare un meccanismo di autenticazione e
riservatezza a un livello inferiore al primo (quello di applicazione), con
IPv6 è stato progettata la possibilità di intervenire al livello del
-collegamento (il terzo) prevendo due apposite estensioni che possono essere
+collegamento (il terzo) prevedendo due apposite estensioni che possono essere
usate per fornire livelli di sicurezza a seconda degli utenti. La codifica
generale di questa architettura è riportata nell'RFC 2401.
I pacchetti autenticati e crittografati portano un indice dei parametri di
sicurezza (SPI, \textit{Security Parameter Index}) che viene negoziato prima
di ogni comunicazione ed è definito dalla stazione sorgente. Nel caso di
-multicast dovà essere lo stesso per tutte le stazioni del gruppo.
+multicast dovrà essere lo stesso per tutte le stazioni del gruppo.
\subsection{Autenticazione}
Il primo meccanismo di sicurezza è quello della testata di autenticazione
incrementare di pacchetto in pacchetto.
Completano la testata i dati di autenticazione che contengono un valore di
-controllo di intgrità (ICV, \textit{Integrity Check Value}), che deve essere
+controllo di integrità (ICV, \textit{Integrity Check Value}), che deve essere
di dimensione pari a un multiplo intero di 32 bit e può contenere un padding
per allineare la testata a 64 bit. Tutti gli algoritmi di autenticazione
devono provvedere questa capacità.
\end{pspicture}
\end{center}
-La modalit`\a tunnel può essere utilizzata sia per comunicazioni fra stazioni
+La modalità tunnel può essere utilizzata sia per comunicazioni fra stazioni
singole che con un gateway di sicurezza; in questa modalità
modifica dell'MD5 chiamata \textit{keyed MD5} che combina alla codifica anche
una chiave che viene inserita all'inizio e alla fine degli altri campi.
+
\subsection{Riservatezza}
\label{sec:ecry}
\label{tab:net_osilayers}
\end{table}
-Il modello ISO/OSI è stato sviluppato corrispondentemente alla definizione
+Il modello ISO/OSI è stato sviluppato in corrispondenza alla definizione
della serie di protocolli X.25 per la commutazione di pacchetto. Ma nonostante
il lavoro dettagliato di standardizzazione il modello si è rivelato
sostanzialmente troppo complesso e poco flessibile rispetto a quello,
\label{fig:net_tcpip_data_flux}
\end{figure}
-La struttura della comuniczione pertanto si può riassumere nei seguenti passi:
+La struttura della comunicazione pertanto si può riassumere nei seguenti passi:
\begin{itemize}
\item Le singole applicazioni si scambieranno i dati secondo un loro formato
specifico, implementando un protocollo di applicazione (esempi possono
\item L'ultimo passo è il trasferimento del pacchetto al driver della
interfaccia di trasmissione che si incarica di incapsularlo nel relativo
protocollo di trasmissione fisica usato dall'hardware usato per la
- comunicazione (ad esempio ethernet per una scheda di rete).
+ comunicazione (ad esempio Ethernet per una scheda di rete).
\end{itemize}
\secref{sec:xxx_multicast}), che è opzionale in IPv4.
\item \textsl{ARP} \textit{Address Resolution Protocol}. È il protocollo che
mappa un indirizzo IP in un indirizzo hardware (come un indirizzo
- internet). È usato in reti di tipo broadcast come ethernet, token ring o
+ internet). È usato in reti di tipo broadcast come Ethernet, Token Ring o
FDDI ma non serve in connessioni punto-punto.
\item \textsl{RARP} \textit{Reverse Address Resolution Protocol}. È il
protocollo che mappa un indirizzo hardware in un indirizzo IP. Viene usato a
Inoltre TCP è in grado di preservare l'ordine dei dati assegnando un numero di
sequenza ad ogni byte che trasmette. Ad esempio se un'applicazione scrive 3000
-bytes su un socket TCP, questi potranno essere spezzati dal protocollo in due
+byte su un socket TCP, questi potranno essere spezzati dal protocollo in due
segmenti (le unità di dati passate da TCP a IP vengono chiamate
-\textit{segment}) di 1500 bytes, di cui il primo conterrà il numero di
+\textit{segment}) di 1500 byte, di cui il primo conterrà il numero di
sequenza $1-1500$ e il secondo il numero $1501-3000$. In questo modo anche se
i segmenti arrivano a destinazione in un ordine diverso, o se alcuni arrivano
più volte a causa di ritrasmissioni dovute alla perdita dei ricevuto,
Un elenco di questi limiti è il seguente, insieme ad un breve accenno alle
loro origini ed alle eventuali implicazioni che possono avere:
\begin{itemize}
-\item La dimensione massima di un pacchetti IP è di 65535 bytes, compreso
+\item La dimensione massima di un pacchetti IP è di 65535 byte, compreso
l'header. Questo è dovuto al fatto che la dimensione è indicata da un campo
apposito nell'header di IP che è lungo 16 bit (vedi
\tabref{tab:IP_ipv4head}).
-\item La dimensione massima di un pacchetto normale di IPv6 è di 65575 bytes,
+\item La dimensione massima di un pacchetto normale di IPv6 è di 65575 byte,
il campo apposito nell'header infatti è sempre a 16 bit, ma la dimensione
dell'header è fissa e di 40 byte e non è compresa nel valore indicato dal
suddetto campo. Inoltre IPv6 ha la possibilità di estendere la dimensione di
un pacchetto usando la \textit{jumbo payload option}.
-\item Molte reti fisiche hanno un MTU (\textit{maximum tranfer unit}) che
+\item Molte reti fisiche hanno un MTU (\textit{maximum transfer unit}) che
dipende dal protocollo specifico usato al livello di link. Il più comune è
- quello dell'ethernet che è pari a 1500 bytes, una serie di valori possibili
+ quello dell'Ethernet che è pari a 1500 byte, una serie di valori possibili
sono riportati in \ntab.
\end{itemize}
X.25 & 576 \\
\hline
\end{tabular}
- \caption{Valori della MTU (\textit{maximum tranfer unit}) per una serie di
+ \caption{Valori della MTU (\textit{maximum transfer unit}) per una serie di
reti diverse.}
\label{tab:net_mtu_values}
\end{table}
pacchetto non deve essere frammentato; un router che riceva un pacchetto le
cui dimensioni eccedano quelle dell'MTU della rete di destinazione genererà un
messaggio di errore ICMPv4 di tipo \textit{destination unreachable,
- fragentation needed but DF bit set}.
+ fragmentation needed but DF bit set}.
Dato che i router IPv6 non possono effettuare la frammentazione la ricezione
di un pacchetto di dimensione eccessiva per la ritrasmissione genererà sempre
Nelle motivazioni in cui si introduce la GNU Free Documentation License (FDL)
(reperibili su http://www.gnu.org/philosophy/free-doc.html) si dà una grande
rilevanza all'importanza di disporre di buoni manuali, in quanto la fruibilità
-e la possilità di usare appieno il software libero, vengono notevolmente
+e la possibilità di usare appieno il software libero, vengono notevolmente
ridotte senza la presenza di un valido manuale che sia altrettanto liberamente
disponibile.
descritti nel testo è lo GNU GCC.
Infine, dato che lo scopo del progetto è la produzione di un libro, si è
-scelto di usare Latex come "ambiente di sviluppo" del medesimo, sia per
+scelto di usare LaTex come "ambiente di sviluppo" del medesimo, sia per
l'impareggiabile qualità tipografica ottenibile, che per la congruenza dello
strumento, tanto sul piano pratico, quanto su quello filosofico.
Come è evidente questa funzione ha molti vantaggi, e permette di evitare i
problemi di memory leak non essendo più necessaria la deallocazione esplicita;
una delle ragioni principali per usarla è però che funziona anche quando si
-usa \func{longjump} per uscire con un salto non locale da una funzione (vedi
+usa \func{longjmp} per uscire con un salto non locale da una funzione (vedi
\secref{sec:proc_longjmp}),
Un altro vantaggio e che in Linux la funzione è molto veloce e non viene
caso \var{errno} è settata ad uno dei valori seguenti:
\begin{errlist}
\item \macro{ENOMEM} alcuni indirizzi dell'intervallo specificato non
- corripondono allo spazio di indirizzi del processo o si è ecceduto il
+ corrispondono allo spazio di indirizzi del processo o si è ecceduto il
numero massimo consentito di pagine bloccate.
\item \macro{EPERM} il processo non ha i privilegi richiesti per
l'operazione.
\var{errno} è settata ad uno dei valori seguenti:
\begin{errlist}
\item \macro{ENOMEM} alcuni indirizzi dell'intervallo specificato non
- corripondono allo spazio di indirizzi del processo.
+ corrispondono allo spazio di indirizzi del processo.
\item \macro{EINVAL} \var{len} non è un valore positivo.
\end{errlist}
\end{functions}
Lo standard ANSI C, pur lasciando alle varie implementazioni i contenuti,
definisce la funzione \func{getenv} che permetta di ottenere i valori delle
-varibili di ambiente, il suo prototipo è:
+variabili di ambiente, il suo prototipo è:
\begin{prototype}{stdlib.h}{char *getenv(const char *name)}
Esamina l'ambiente del processo cercando una stringa che corrisponda a
La funzione ritorna zero quando è chiamata direttamente e un valore diverso
da zero quando ritorna da una chiamata di \func{longjmp} che usa il contesto
- salvato in predenza.
+ salvato in precedenza.
\funcdecl{void longjmp(jmp\_buf env, int val)}
Ripristina il contesto dello stack salvato dall'ultima chiamata di
\func{setjmp} con l'argomento \param{env}. Il programma prosegue dal ritorno
di \func{setjmp} con un valore \param{val}. Il valore di \param{val} deve
- essere diverso da zero, se viene specficato 0 sarà usato 1 al suo posto.
+ essere diverso da zero, se viene specificato 0 sarà usato 1 al suo posto.
La funzione non ritorna.
\end{functions}
\chapter{Il controllo di sessione}
\label{cha:session}
+
+
\section{Il login}
\label{sec:sess_login}
+
\subsection{Il login da terminale}
\label{sec:sess_term_log}
+
\subsection{Il login via rete}
\label{sec:sess_net_log}
+
\section{Le relazioni fra i processi}
\label{sec:sess_relation}
+
\subsection{I \textit{process group}}
\label{sec:sess_proc_group}
+
\subsection{Le sessioni}
\label{sec:sess_sessions}
+
\subsection{Il terminale di controllo}
\label{sec:sess_ctrl_term}
+
+
\section{Il \textit{job control}}
\label{sec:sess_job_control}
+
\subsection{La shell e i programmi}
\label{sec:sess_shell}
\end{lstlisting}
\normalsize
se un secondo segnale arriva prima che il manipolatore invocato dal primo
-abbia eseguito la re-installazione di se stesso il segnale può essere perso o
+abbia eseguito la reinstallazione di se stesso il segnale può essere perso o
causare il comportamento originale assegnato al segnale (in genere la
terminazione del processo).
% Un'altra caratteristica della implementazione inaffidabile è che le chiamate
% di sistema non sono fatte ripartire automaticamente quando sono interrotte da
% un segnale, per questo un programma deve controllare lo stato di uscita della
-% chiamata al sistema e riperterla nel caso l'errore riportato da \texttt{errno}
+% chiamata al sistema e ripeterla nel caso l'errore riportato da \texttt{errno}
% sia \texttt{EINTR}.
Questo ci mostra ad esempio come con la semantica inaffidabile non esista una
% Per questo segnale le cose sono complicate dal fatto che possono esserci
% molte diverse eccezioni che \texttt{SIGFPE} non distingue, mentre lo
-% standard IEEE per le operazioni in virgola mobile definisce vaire eccezioni
+% standard IEEE per le operazioni in virgola mobile definisce varie eccezioni
% aritmetiche e richiede che esse siano notificate.
\item[\macro{SIGILL}] Il nome deriva da \textit{illegal instruction},
inizializzato leggendo al di la della fine di un vettore.
\item[\macro{SIGBUS}] Il nome deriva da \textit{bus error}. Come
\macro{SIGSEGV} questo è un segnale che viene generato di solito quando si
- dereferenzia un puntatore non inzializzato, la differenza è che
+ dereferenzia un puntatore non inizializzato, la differenza è che
\macro{SIGSEGV} indica un accesso non permesso su un indirizzo esistente
(tipo fuori dallo heap o dallo stack), mentre \macro{SIGBUS} indica
l'accesso ad un indirizzo non valido, come nel caso di un puntatore non
Program Interface}) usata nella programmazione di rete. La loro origine
risale al 1983, quando furono introdotti nel BSD 4.2; l'interfaccia è rimasta
sostanzialmente la stessa con piccole modifiche negli anni successivi. Benché
-siano state sviluppate interfacce alternative, originate dai sistemi SYSV,
+siano state sviluppate interfacce alternative, originate dai sistemi SVr4,
come la XTI (\textit{X/Open Transport Interface}) nessuna ha mai raggiunto la
diffusione e la popolarità di quella dei socket (né tantomeno usabilità e
flessibilità).
La scelta di uno stile dipende sia dai meccanismi disponibili, sia dal tipo di
comunicazione che si vuole effettuare. Ad esempio alcuni stili di
-comunicazione considerano i dati come una sequenza continua di bytes, altri
+comunicazione considerano i dati come una sequenza continua di byte, altri
invece li raggruppano in blocchi (i pacchetti).
Un'altro esempio di stile concerne la possibilità che la comunicazione possa o
maneggiare puntatori a strutture relative a tutti gli indirizzi possibili
nelle varie famiglie di protocolli; questo pone il problema di come passare
questi puntatori, il C ANSI risolve questo problema coi i puntatori generici
-(i \type{void *}), ma l'interfaccia dei socket è antecendente alla
+(i \type{void *}), ma l'interfaccia dei socket è antecedente alla
definizione dello standard ANSI, e per questo nel 1982 fu scelto di definire
una struttura generica \type{sockaddr} per gli indirizzi dei socket mostrata
in \nfig:
(tenuta in uno spazio di nomi astratto). Nel primo caso l'indirizzo viene
specificato come una stringa (terminata da uno zero) corrispondente al
pathname del file; nel secondo invece \var{sun\_path} inizia con uno zero
-vengono usati i restanti bytes come stringa (senza terminazione).
+vengono usati i restanti byte come stringa (senza terminazione).
% \subsection{Il passaggio delle strutture}
Il problema connesso all'endianess è che quando si passano dei dati da un tipo
di architettura all'altra i dati vengono interpretati in maniera diversa, e ad
-esempio nel caso dell'intero a 16 bit ci si ritroverà con i due bytes in cui è
+esempio nel caso dell'intero a 16 bit ci si ritroverà con i due byte in cui è
suddiviso scambiati di posto, e ne sarà quindi invertito l'ordine di lettura
per cui, per riavere il valore originale dovranno essere rovesciati.
indirizzi valida.
\end{prototype}
-Gli indirizzi vengono cnovertiti da/alle rispettive strutture di indirizzo
+Gli indirizzi vengono convertiti da/alle rispettive strutture di indirizzo
(\var{struct in\_addr} per IPv4, e \var{struct in6\_addr} per IPv6), che
devono essere precedentemente allocate e passate attraverso il puntatore
\var{addr\_ptr}; il parametro \var{dest} di \func{inet\_ntop} non può essere
Per evitare di rendere questa introduzione ai socket puramente teorica
iniziamo con il mostrare un esempio di un client TCP elementare. Prima di
-passare agli esempi del client e del server, esamimeremo una caratteristica
+passare agli esempi del client e del server, esamineremo una caratteristica
delle funzioni di I/O sui socket che ci tornerà utile anche in seguito.
per i socket di tipo stream).
Infatti con i socket è comune che funzioni come \func{read} o \func{write}
-possano restituire in input o scrivere in output un numero di bytes minore di
+possano restituire in input o scrivere in output un numero di byte minore di
quello richiesto. Come già accennato in \secref{sec:file_read} questo è un
comportamento normale anche per l'I/O su file, e succede
perché si eccede in lettura o scrittura il limite di buffer del kernel.
In questo caso tutto quello che il programma chiamante deve fare è di ripetere
-la lettura (o scrittura) per la quantità di bytes rimanenti (lo stesso può
-avvenire scrivendo più di 4096 bytes in una pipe, dato che quello è il limite
+la lettura (o scrittura) per la quantità di byte rimanenti (lo stesso può
+avvenire scrivendo più di 4096 byte in una pipe, dato che quello è il limite
di solito adottato per il buffer di trasmissione del kernel).
\begin{figure}[htb]
return (count - nleft);
}
\end{lstlisting}
- \caption{Funzione \func{SockRead}, legge \var{count} bytes da un socket }
+ \caption{Funzione \func{SockRead}, legge \var{count} byte da un socket }
\label{fig:sock_SockRead_code}
\end{figure}
Per questo motivo seguendo l'esempio di W. R. Stevens si sono definite due
funzioni \func{SockRead} e \func{SockWrite} che eseguono la lettura da un
socket tenendo conto di questa caratteristica, ed in grado di ritornare dopo
-avere letto o scritto esattamente il numero di bytes specificato; il sorgente
+avere letto o scritto esattamente il numero di byte specificato; il sorgente
è riportato in \curfig\ e \nfig\ ed è disponibile fra i sorgenti allegati alla
guida nei files \file{SockRead.c} e \file{SockWrite.c}.
return (count);
}
\end{lstlisting}
- \caption{Funzione \func{SockWrite}, scrive \var{count} bytes su un socket }
+ \caption{Funzione \func{SockWrite}, scrive \var{count} byte su un socket }
\label{fig:sock_SockWrite_code}
\end{figure}
Come si può notare le funzioni ripetono la lettura/scrittura in un ciclo fino
-all'esaurimento del numero di bytes richiesti, in caso di errore viene
+all'esaurimento del numero di byte richiesti, in caso di errore viene
controllato se questo è \macro{EINTR} (cioè un'interruzione della system call
dovuta ad un segnale), nel qual caso l'accesso viene ripetuto, altrimenti
l'errore viene ritornato interrompendo il ciclo.
-Nel caso della lettura, se il numero di bytes letti è zero, significa che si è
+Nel caso della lettura, se il numero di byte letti è zero, significa che si è
arrivati alla fine del file e pertanto si ritorna senza aver concluso la
-lettura di tutti i bytes richiesti.
+lettura di tutti i byte richiesti.
\begin{lstlisting}{}
#include <sys/types.h> /* predefined types */
#include <unistd.h> /* include unix standard library */
-#include <arpa/inet.h> /* IP addresses conversion utiliites */
+#include <arpa/inet.h> /* IP addresses conversion utilities */
#include <sys/socket.h> /* socket library */
#include <stdio.h> /* include standard I/O library */
Il programma anzitutto include gli header necessari (\texttt{\small 1--5});
dopo la dichiarazione delle variabili (\texttt{\small 9--12}) si è omessa
tutta la parte relativa al trattamento degli argomenti passati dalla linea di
-comando (effettuata con le apposite routines illustrate in
+comando (effettuata con le apposite routine illustrate in
\capref{sec:proc_opt_handling}).
Il primo passo (\texttt{\small 14--18}) è creare un \textit{socket} IPv4
\begin{lstlisting}{}
#include <sys/types.h> /* predefined types */
#include <unistd.h> /* include unix standard library */
-#include <arpa/inet.h> /* IP addresses conversion utiliites */
+#include <arpa/inet.h> /* IP addresses conversion utilities */
#include <sys/socket.h> /* socket library */
#include <stdio.h> /* include standard I/O library */
#include <time.h>
projects / gapil.git / commitdiff