16.3. Formato del file di configurazione PAM
Ogni file di configurazione PAM contiene un gruppo di direttive formattate come segue:
<module interface> <control flag> <module name> <module arguments> |
Ciascuno di questi elementi � spiegato nelle sezioni successive.
16.3.1. Interfaccia del modulo
Esistono quattro tipi di interfacce di moduli PAM che permettono di controllare l'accesso a determinati servizi e sono correlati ad aspetti diversi del processo di autorizzazione:
auth — Questa interfaccia del modulo autentica l'uso. Per esempio, esso richiede e verifica la validit� di una password. I moduli con questa interfaccia possono anche impostare delle credenziali come l'appartenenza al gruppo o i ticket di Kerberos.
account — Questo modulo esegue un controllo per verificare che l'accesso sia abilitato. Per esempio, controlla se un account � scaduto o se l'utente ha il permesso di collegarsi ad una determinata ora del giorno.
password — Questa interfaccia imposta e verifica le password.
session — Questa interfaccia configura e gestisce le sessioni dell'utente. I moduli con questa interfaccia, possono effettuare ulteriori compiti richiesti per autorizzare l'accesso, per esempio montando la home directory dell'utente o rendendo disponibile la sua mailbox.
 | Nota Bene |
|---|
| | Un singolo modulo pu� fornire una o tutte le interfacce del modulo.Per esempio pam_unix.so fornisce tutti e quattro le interfacce del modulo. |
In un file di configurazione PAM l'interfaccia del modulo � il primo aspetto definito. Per esempio una riga tipica di configurazione potrebbe essere:
auth required pam_unix.so |
Ci� indica a PAM di utilizzare l'interfaccia auth del modulo pam_unix.so.
16.3.1.1. Stacking delle interfacce del modulo
Le direttive dell'interfaccia del modulo possono essereconservate o messe l'una sull'altra, in modo tale che moduli multipli possano essere utilizzati insieme per un unico scopo. L'ordine con cui vengono elencati i moduli � molto importante per il processo di autenticazione.
Tale operazione rende pi� facile per l'amministratore richiedere la verifica di determinate condizioni prima di autenticare l'utente. Per esempio, rlogin utilizza normalmente almeno cinque moduli auth, come lo dimostra il suo file di configurazione PAM:
auth required pam_nologin.so
auth required pam_securetty.so
auth required pam_env.so
auth sufficient pam_rhosts_auth.so
auth required pam_stack.so service=system-auth |
Prima che qualcuno possa usare rlogin, PAM controlla che non esista alcun file /etc/nologin, verifica se si stia provando ad effettuare un collegamento remoto come utente root attraverso una connessione di rete,e se vi sia la possibilit� di caricare tutte le variabili d'ambiente. Quindi, se viene eseguita con successo un'autenticazione rhosts, il collegamento viene abilitato. Se l'autenticazione rhosts non va a buon fine, viene effettuata un'autenticazione standard della password.
16.3.2. Control Flag
Quando vengono controllati, tutti i moduli PAM generano un risultato positivo o negativo. I Control flag indicano a PAM cosa fare con il risultato. Poich� i moduli possono essere ordinati in determinati modi, i control flag permettono di stabilire l'importanza di un risultato positivo o negativo di un particolare modulo per l'autenticazione dell'utente al servizio.
Ci sono quattro control flag predefinite:
required — Il modulo deve superare il controllo perch� l'autenticazione sia autorizzata. Se il controllo di un modulo required fallisce, l'utente non ne viene avvisato finch� tutti gli altri moduli dello stesso tipo non sono stati controllati.
requisite — il modulo deve superare la verifica perch� l'autenticazione vada a buon fine. Tuttavia, se la verifica di un modulo requisite fallisce, l'utente ne viene immediatamente avvisato tramite un messaggio che richiama il primo modulo required o requisite.
sufficient — Il risultato del modulo viene ignorato se fallisce. Tuttavia, se il risultato del modulo con opzione sufficient supera la verifica e nessun modulo con opzione required che lo precedono abbia fallito, non viene richiesto nessun altro risultato e l'utente viene autenticato.
optional — Il risultato del modulo viene ignorato.L'unico caso in cui un modulo con opzione optional � necessario ai fini dell'autenticazione � quando non ci sono altri moduli che si riferiscono all'interfaccia.
 | Importante |
|---|
| | L'ordine con il quale i moduli required sono chiamati non � importante. I control flag sufficient e requisite invece, conferiscono una certa importanza all'ordine. |
Adesso � disponibile una nuova sintassi di controllo ancora pi� efficace per PAM. Per maggiori informazioni, consultate la documentazione su PAM contenuta nella directory /usr/share/doc/pam-numero-versione/ (dove numero-versione � il numero della versione per PAM).
16.3.3. Nome del modulo
Il nome del modulo fornisce a PAM il nome del modulo 'pluggable' contenente l'interfaccia del modulo specificato. Con le vecchie versioni di Red Hat Enterprise Linux, il percorso intero per il modulo veniva fornito all'interno del file di configurazione di PAM, come ad esempio /lib/security/pam_stack.so. Tuttavia con l'avvento di sistemi con librerie multiple, i quali possono conservare moduli PAM a 64-bit all'interno della directory /lib64/security/, il nome della directory viene omesso perch� le applicazioni sono collegate alla versione appropriata di libpam, la quale pu� trovare la versione corretta del modulo.
16.3.4. Argomenti del modulo
PAM utilizza degli argomenti per fornire informazioni a un modulo pluggable durante il processo di autenticazione di un determinato tipo di modulo.
Per esempio il modulo pam_userdb.so utilizza file nascosti del Berkeley DB per autenticare l'utente. Il Berkeley DB � un database Open Source concepito per essere incorporato in varie applicazioni. Il modulo prende un argomento db specificando il file Berkeley DB da usare, che pu� variare in funzione del servizio.
Pertanto la riga pam_userdb.so di un file di configurazione PAM �:
auth required pam_userdb.so db=<path-to-file> |
Nell'esempio precedente, sostituire <percorso-per-file> con il percorso completo per il file del database Berkeley DB.
Gli argomenti non validi vengono ignorati e non influenzano il successo n� il fallimento del modulo PAM. Tuttavia, molti moduli riporteranno un errore sul file /var/log/messages.
