5.3. PAM - Pluggable Authentication Modules

Adesso si dovrebbe aver compreso che, in Unix, ci sono molti protocolli dati (FTP, HTTP, telnet, IRC, eccetera) e loro implementazioni (vsftpd, Apache, telnetd, dancer-ircd, eccetera).

Siccome molti dei servizi richiedono l'autenticazione dell'utente, diventa ovvio che supportare tutti i tipi di autenticazione in ogni servizio sarebbe difficile, richiederebbe un sacco di lavoro manuale e ripetitivo e sarebbe passibile di errori. In aggiunta, le implementazioni finirebbero molto probabilmente per essere incoerenti, avendo differenti interpretazioni degli "standard" e contenendo subdoli bug difficili da scovare.

Fortunatamente, la scienza dei computer è vecchia a sufficienza, tanto che la gente è riuscita a capire il problema, e a pensare ad eventuali rimedi. L'idea che Sun Microsystems ha avuto è stata un generico livello "Pluggable Authentication Module", o semplicemente "PAM". Generalmente, ogni servizio crea un contatto chiaro con PAM e si aspetta una risposta di tipo "sì" o "no". Ciò permette un approccio di tipo un metodo per tutti nel software client; per realizzare tutto il lavoro di autenticazione, invocare semplicemente PAM e non ci si preoccupi di altro.

Anche se PAM restituisce solo una risposta finale positiva o negativa, si potrebbe supporre che PAM usi molte tecniche sofisticate nell'arrivare a questa conclusione booleana (Sì/No). E infatti è così. Ciascun servizio mette una parte della sua configurazione PAM ne file di configurazione di PAM. Quella configurazione può richiedere la realizzazione di passi di autenticazione arbitrari, combinati e impilati in qualsiasi ordine (incluso le varianti uno o l'altro). C'è anche un default che si può utilizzare per gestire servizi multipli con il medesimo file di configurazione.

Per esempio si potrebbe configurare PAM per autenticare l'utente se o la sua scansione della retina corrisponde al database, o possiede sia la chiave RSA privata corretta, sia la password usa e getta. E supportare un altro schema di autenticazione diventa così facile come scrivere un modulo PAM per gestire il metodo specifico.

Ci sono tre implementazioni principali di PAM in uso oggi: PAM di Solaris utilizzato dal sistema operativo Solaris, Linux-PAM utilizzato da tutte le "distribuzioni" Linux e OpenPAM usato dai sistemi BSD-derivati.

Linux-PAM è anche l'implementazione di PAM usata da Debian. Un fattore molto sfortunato è che, mentre PAM stesso fornisce una API standardizzata anche per richiedere input aggiuntivi dall'utente (che è un'impresa), esso non standardizza l'interfaccia di log. Alcuni moduli Linux-PAM non creano affatto un log e quelli che lo fanno non sono forzati alla coerenza tramite metodi formali. Questa è una carenza così critica che conseguentemente mette l'uso pratico di PAM sotto una luce completamente diversa.

La soluzione al problema del log di PAM, tuttavia, arrivò inaspettatamente. Sebastien Tricaud ha aggiunto il supporto Prelude a PAM 0.79, così PAM può ora riportare in modo consistente tutte le operazioni al gestore Prelude.