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

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

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