Newsgroup: it.comp.os.linux.sys
Titolo: problema con pam

Sto provando a fa interagire pam con mysql (al fine di integrarlo in 
postfix)
In pratica sembra che ci sia una cache che memorizza le password.
Ecco i dettagli:
/etc/pam.d/smtp:
auth    required   pam_mysql.so user=mail_admin
	passwd=passwdcolumn host=127.0.0.1
	db=db table=table usercolumn=usercolumn
	passwdcolumn=passwdcolumn crypt=1
account .. uguale..
Popolato il db con 1 utente, e password criptata "pippo", accade che:
testsaslauthd -s smtp -u utente -p pippo
0: OK "Success."
se però nel db cambio la password in "pluto" ottengo sempre "0: OK 
"Success.", fino a quando non scrivo la seguente:
testsaslauthd -s smtp -u utente -p pluto
0: OK "Success."
Dopo di ciò pippo non funziona più (finalmente!)
In pratica pam non accede più al db fino a quando non lo interrogo con 
una nuova password. Fin quando utilizzo quella vecchia va a dritto con 
il vecchio risultato.
Ho provato a ricompilare pam_mysql fornendo altri log, e anche ad 
utilizzare pam_python per vedere cosa succedeva, ed è la stessa storia: 
fino a quando utilizzo la stessa password pam non chiama l'handler 
relativo (in questo caso "smtp", che utilizza pam_mysql o pam_python).
Possibile? Pam memorizza il risultato da qualche parte? Oppure il 
problema è altrove?
Può essere che la descrizione del problema sia parzialmente errata, in 
quanto ho fatto le cose velocemente e ho avuto un po' di problemi con i 
log, ma il risultato è quello descritto.
Alessandro

Scusate, ovviamente prima parlavo di sasl, tramite pam su mysql.
Il problema sembra proprio essere sasl; anche sul db locale di default 
/etc/sasldb2 ho lo stesso problema di "caching"
Alessandro

 Scusate, ovviamente prima parlavo di sasl, tramite pam su mysql.
Non capisco perchè devi fare
postfix -> sasl -> pam -> mysql
quando 
postfix -> sasl -> mysql
è più corto, veloce, semplice e funzionale e non contiene quella parolina 
di 3 lettere che di solito fa solo incazzare.


http://www.postfix.org/SASL_README.html#auxprop_sql
"""
If you must store encrypted passwords, you cannot use the sql auxprop 
plugin. Instead, see section "Using saslauthd with PAM", and configure 
PAM to look up the encrypted passwords with, for example, the pam_mysql 
module.
"""
Poiché userò una connessione criptata potrò usare le password in chiaro, 
ma un po' mi scoccia (anche solo per evitare chiamate tipo "tu che vedi 
le password mi dici quale è la mia...").
Comunque è sasl che mi fa perdere tempo:
saslpasswd2 testtest [inserisco 'provaprova1']
testsaslauthd  -u testtest -p provaprova1
0: OK "Success."   OK
saslpasswd2 testtest [inserisco 'provaprova']
testsaslauthd  -u testtest -p provaprova1
0: OK "Success."   ERRATO
testsaslauthd  -u testtest -p provaprova
0: OK "Success."   OK
testsaslauthd  -u testtest -p provaprova1
0: NO "authentication failed"    OK
Alessandro

 di appartenenza e non li vedeva.
E' una debian squeeze, ma lenny ma si comporta in modo identico.
Come si chiamava il demone?
Qui non trovo nulla, i seguenti danno risultati vuoti
dpkg -l|grep cach -i
ps ax|grep cach -i
Alessandro

 Come si chiamava il demone?
nscd credo

 nscd credo
si, direi che è quello dalla descrizione del pacchetto, ma qui non è 
istallato


Stavo per scrivere sulla ml di sasl, e per descrivere bene la 
configurazione stavo postando anche il file /etc/default/saslauthd
#> cat /etc/default/saslauthd |grep -v "^#"|grep -v "^$"
START=yes
DESC="SASL Authentication Daemon"
NAME="saslauthd"
MECHANISMS="sasldb"
MECH_OPTIONS=""
THREADS=5
OPTIONS="-c -m /var/spool/postfix/var/run/saslauthd"
Guardando le opziondi di saslauthd è venuto fuori che:
-c         Enable credential caching.
Rimossa tale opzione tutto funziona come previsto. :-)
Poichè questo era il file di default (a parte il MECHANISMS) immagino 
che questa opzione interessi a molti
Alessandro