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

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

On Tue, 16 Apr 2002, Andrew Morgan wrote:

> Jan Rekorajski wrote:
> > > 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).
> 
> The return code is not discarded, it is just not used in determining
> what chain to follow - the first call 'freezes the chain' - the second
> simply follows the path set by the first. Pretty much the return codes
> accumulate as if the frozen chain was all 'required' (with some
> exceptions for 'optional' modules).

Ah, it's clear now.

> > > 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.
> 
> To some extent this is necessary for other password modules too. Why is
> this objectionable in your case?

It's just strange that PRELIM_CHECK drives the chain, but the actual
work is done in the second invocation. It may be confusing.

> > > 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.
> 
> It only makes it useless if your module is expecting to drive the module
> stack differently on the second invocation. The complaint that led to
> this being the behavior is that having a module behave differently on
> its second invocation is generally confusing for the sys admin. If you
> recall, the conventional advice at the time was "don't let your module
> return differently each time", but not being an enforced rule, that
> didn't actually work.

I finally got that, thanks :) But what about the errors that may happen
on the second run? Frozen chain says succes and then its error, is this
covered?

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