freezing chain/caching retval breaks [token=value] syntax

[Jan Rekorajski <baggins-pam sith mimuw edu pl>]

With the introduction of FREEZE_CHAIN in 0.74 the [token=value] syntax
became useless (at least for sm_chauthtok). Long description follows.

I have this in my /etc/pam.d/passwd:

password  [success=ok ignore=1 default=bad]   /lib/security/pam_pwgen.so
password  [success=1 default=bad]   /lib/security/pam_cracklib.so use_authtok
password  required        /lib/security/pam_cracklib.so retry=3
password  required        /lib/security/pam_unix.so shadow use_authtok

pam_pwgen is a fancy password generator, now what _should_ happen:
if the user decides to use pwgen the module returns PAM_SUCCESS, control
is passed to 'pam_cracklib.so use_authtok' just to doublecheck and if
everything is ok the second pam_cracklib should be skipped. If the user
does not want pwgen the module returns PAM_IGNORE,
'pam_cracklib.so use_authtok' should be skipped and normal pam_cracklib
kicks in.

But, the chached_retval logic introduced in 0.74 breaks this. There
were/are always two calls to sm_chauthtok modules - PAM_PRELIM_CHECK and
the real thing. Now PAM_PRELIM_CHECK returns PAM_SUCCES, this gets
cached and later the real return code is overriden with the cached one
making [success=ok ignore=1 default=bad] configuration meaningles.

We can solve it by not freezing the chain for chauthtok, or to ignore
chached retval if it's PAM_SUCCESS. I'm not that familiar with the
internals of pam library to come with a good solution myself, but this
really needs fixing.

Jan
-- 
Jan Rękorajski            |  ALL SUSPECTS ARE GUILTY. PERIOD!
baggins<at>mimuw.edu.pl   |  OTHERWISE THEY WOULDN'T BE SUSPECTS, WOULD THEY?
BOFH, MANIAC              |                   -- TROOPS by Kevin Rubio