Prog1998 < Lab_so_1/AL

Tags: view all tags

<html>

<h1>
<font size=+2>Laboratorio II: Sistemi Operativi - a.a. 1998/99</font></h1>
<b><blink><font size=+1>La consegna va effettuata entro 22 gennaio 1999.</font></blink></b>
<h2>
<font size=+1>Sviluppo di un proxy per un servente POP (Post Office Protocol)</font></h2>
<font color="#FF0000"><font size=+1>Sono facoltative le seguenti richieste
(in ordine crescente di importanza):</font></font>
<br><font size=+1>1) istallazione automatica. Si richiede di automatizzare
la procedura descritta nel file INSTALL accluso nel sorgente del qpopper.
Uno script in perl dovrebbe eseguire automaticamente le indicazioni contenute
nel file.</font>
<p><font size=+1>2) file di log. Il proxy potrebbe registrare in un suo
file di log vari tipi di informazioni, ad esempio solo le connessioni,
le richieste eseguite da ogni connessione, il contenuto dei messaggi, ecc.
Si richiede sia di definire le informazioni utili da mantenere sia di estendere
il proxy con questa funzione.</font>
<p><font size=+1>3) Valutazione delle prestazioni.</font>
<br><font size=+1>3.a)Si richiede di valutare "il costo globale" dovuto
all'introduzione del proxy. Ad esempio, si potrebbe misurare e confrontare
il tempo impiegato per leggere una email di varie dimensioni senza/con
il proxy. Data la necessita' di isolare l'errore di misura introdotto dal
carico di fondo della rete dei laboratori, una misura dal vivo risulta
complessa, bisognerebbe pero' almeno descrivere come una misura del genere
puo' essere impostata.</font>
<br><font size=+1>3.b) Si richiede la comparazione fra la versione monoprocesso
e quella multiprocesso. Descrivere almeno come la misura puo' essere eseguita.</font>
<br>&nbsp;
<h3>
Introduzione</h3>
Normalmente, gli utenti accedono la propria posta, mail, leggendo un file
sulla macchina dove e' stata "consegnata" tramite il protocollo SMTP (Simple
Mail Transfer Protocol). A volte e' utile usare un meccanismo diverso basato
su un servente, mail server, che mantiene e distribuisce su richiesta la
posta ai singoli utenti (tipicamente questo schema e' utilizzato dai provider
Internet). Il protocollo POP (<b>RFC 1725</b>) permette di accedere la
propria posta elettronica gestita da un mail server. Esistono diversi programmi
che possono svolgere le funzioni di clienti POP. Tra i piu' noti vi sono
Eudora ed i Web browser piu' diffusi: Netscape, Internet Explorer.
<p>Per controllare gli accessi ed evitare che si possa leggere la posta
elettronica di altri utenti, il protocollo POP richiede l'autenticazione
dell'utente. In genere il meccanismo di controllo degli accessi e' lo stesso
che viene comunemente utilizzato per l'accesso interattivo ai sistemi:
la coppia login,password.
<p>Poiche' in molti casi la password viaggia in "chiaro" tra il cliente
ed il server, si ha un potenziale problema di sicurezza perche' la password
puo' essere intercettata e riutilizzata da altri (e non solo per l'accesso
alla posta elettronica).
<p>Esistono implementazioni del POP che cercano di risolvere questo problema
ricorrendo a Kerberos o sfruttando password "non riutilizzabili" (<b>APOP</b>).
Purtroppo queste varianti sicure non sono ampiamente diffuse o supportate.
In particolare, non e' possibile utilizzare come POP client i browser piu'
diffusi se l'autenticazione sul server e' di tipo APOP.
<h3>
Scopo del progetto</h3>
Lo scopo del progetto e' lo studio e la realizzazione in Perl di un <b>proxy</b>
che supporti il meccanismo di autenticazione APOP e che quindi consenta
l'utizzo sicuro di un qualsiasi browser come cliente POP. In particolare,
il proxy deve essere in grado di ricevere la password in chiaro inviata
dal browser utilizzato dal cliente e seguire la procedura APOP per accedere
al mail server reale. Una volta autenticato il cliente in modo sicuro sul
mail server, e' necessario:
<ol>
<li>
ricevere i comandi POP inviati dal browser,</li>

<li>
girare le richieste al POP server</li>

<li>
ricevere le risposte (compresi eventuali codici di errore!)</li>

<li>
girare le risposte al browser</li>
</ol>
Si richiede lo sviluppo delle seguenti due versioni:
<ol>
<li>
Monoprocesso: un singolo processo che gestisce multiple connessioni</li>

<li>
Monoconnessione: un processo per ogni connessione (i processi multipli
sono supervisionati da un processo <i>daemon<b>)</b>.</i></li>
</ol>
Particolare attenzione deve essere rivolta all'<b>affidabilita' </b>del
proxy. Un altro importante elemento di valutazione sara' la flessibilita'
del disegno e del codice che devono essere facilmente adattabili a modifiche
del POP e/o all'utilizzo come proxy di altri protocolli.
<p>A completamento del progetto ogni gruppo dovra' consegnare una documentazione
su carta con chiara l'indicazione dei componenti del gruppo (nome, matricola,
anno accademico e recapito). La documentazione dovra' almeno contenere
le informazioni dettagliate di seguito:
<ul>
<li>
Lo scopo del progetto (problema da risolvere, possibili soluzioni...)</li>

<li>
Le scelte di progetto effettuate</li>

<li>
L'organizzazione del codice e delle strutture dati</li>

<li>
Descrizione dei test effettuati per dimostrare l'affidabilita' del prototipo</li>

<li>
Procedure di installazione ed utilizzo. Per questa parte si dovra' usare
formato e notazione consistenti con quelli dei manuali UNIX</li>

<p><br>Come appendice del documento dovra' essere incluso il codice sorgente
Perl.</ul>

<h3>
Bibliografia <font size=+0>(solo consultazione)</font></h3>

<ol>
<li>
Building Internet Firewalls, D.B. Chapman and E.D. Zwicky, O'Reilly &amp;
Ass. 1995</li>

<li>
TCP/IP Network Administration, 2nd Ed., C. Hunt, O'Reilly &amp; Ass., 1998</li>

<li>
Advanced Perl Programming, S. Srinivasan, O'Reilly &amp; Ass., 1997</li>

<li>
Unix Network Programming, R.Stevens, Prentice Hall Software Series, 1990</li>

<li>
POP3: <a href="http://www.eudora.com/freeware">http://www.eudora.com/freeware</a>
definito in <a href="http://cesare.dsi.uniroma1.it/LaboratorioII/rfc/rfc1725.html">rfc1725</a></li>
</ol>

</body>
</html>

-- Users.AntonioValletta - 14 Nov 2001 <br>