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

[Andrew Morgan <morgan transmeta com>]

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