Jan Rekorajski wrote: > > 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. I guess I disagree. Why does PAM_PRELIM_CHECK cause pam_pwgen to always return PAM_SUCCESS? Surely, if pam_pwgen is not going to be used by the user, you can know after its first (PAM_PRELIM_CHECK) invocation? The point about the frozen chain thing is that things that need to be invoked twice, do get invoked twice. In this example, password sufficient pam_foo.so password required pam_bar.so if we follow what you are asking for, then it is possible for foo to get invoked twice and bar only once (and never with PAM_PRELIM_CHECK, causing it to not properly initialize). This is actually what would happen in your example - the retry=3 version of pam_cracklib.so would never get to see PAM_PRELIM_CHECK. With the frozen chain stuff, this doesn't happen. And as such, we guarantee that modules expecting to be called twice are called twice. Cheers Andrew
