On Mon, 15 Apr 2002, Andrew Morgan wrote: > 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? No, the problem is pam_pwgen returns correctly, but because of freeze the second return code is discarded and the one returned by PAM_PRELIM_CHECK is used for decision. Look in libpam/pam_dispatch.c lines 107-170 (main culprit on line 168). > Surely, if pam_pwgen is not going to be used by the user, you can know > after its first (PAM_PRELIM_CHECK) invocation? I could do this but it will make the module into long question-answer game, or I have to somehow save the state between invocations. > 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. I understand this, but problem here is which call should be decisive, now it's the first, and it's almost always SUCCESS thus making [token=value] syntax useless. 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
