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). > > 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? > > 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. Cheers Andrew
