> > > > > o it is not clear to me if I understand PAM_PRELIM_CHECK/PAM_UPDATE > This usage is a feature. One can interpret "checking the availability of > resources" to mean "check if its ok right now for the current applicant > (PAM_RUSER) to change the user's (PAM_USER) authentication token". If > you read it this way, then as part of the 'prelim' check it seems > acceptable to verify that they know the current authtoken (password) > they are about to replace. This is acceptable if we also do one of: 1. Re-check the old password when doing the UPDATE, at least in the case when PAM_PRELIM_CHECK wasn't done. 2. Document it more explicitly that PAM_PRELIM_CHECK is now security critical (it should always be called, and its result should never be ignored) in case of other implementations of PAM that may be using our set of modules. I just don't like adding a security meaning to a non-security feature. Is the Sun implementation safe enough to work with password changing in our modules (and will that work at all)? > This is the interpretation we've adopted. The reason we adopted this > interpretation is that it makes it possible to transparently support a > plug-in new-password strength checker. If you wait for the 'update' > cycle to do this preliminary check, its not clear where in the stack you > can plug the strength checker and have it work. Yes, this makes sense. Signed, Solar Designer
