Solar Designer wrote: > > > > o it is not clear to me if I understand PAM_PRELIM_CHECK/PAM_UPDATE > > > > logic correctly. I verify (possible ask) the current password then > > > > first flag set, and change (and possible ask) the new password then > > > > second is set (current pam_unix does the same). Is this a right > > > > think to do to ask current password in prelim_check? If not, then > > > > we have troubles stacking modules > > > > > > I think you've got it wrong. It was my understanding that the > > > prelim_check is for checking the availability of resources required > > > for the module's functionality, such as configuration files. > > > > This is how things implemented in current pam_unix. This also seemed > > strange to me, and so I asked about it. > > Did you get an answer from Andrew? This is really not specific to > just pam_unix. [I took a little vacation but am slowly catching up again...] 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 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. Cheers Andrew
