On Wed, 14 Mar 2001 sschul04@calvin.edu wrote: > I recall reading in some mailing list archive that in the password stack, > pam_cracklib doesn't behave quite like normal modules. Unfortunately, I > can't find the old message. The difference, as I recall, has something > to do with the fact that pam_cracklib is "called" (correct term?) on > a "second pass" of some sort, only after another module has asked for the > existing password. > > This seems to be confirmed by my experimentation because pam_cracklib is > at the top of my password stack, yet the other modules first prompt for > existing password. In order to get everything to work as desired, I give > my other password modules a use_authtok flag. Then, the sequence is > (paraphrased, sorry it's not in front of me right now) as follows: > > enter current <some_module> password: // a module UNDER pam_cracklib > enter UNIX password: // this is pam_cracklib > re-enter UNIX password: // pam_cracklib again > passwords updated successfully. // presumably, the first module updates > here > > Without use_authtok flags, my other modules re-prompt after the > pam_cracklib prompts. > > Is my understanding of what is happening correct? Can I get pam_cracklib > to initially prompt for the existing password? What's the sequence > of "passes" and when do authtoks get created/passed? Is there somewhere > that I can read documentation so that I don't have to bother the list? Several months ago, I tried getting the "pam_cracklib" module compiled, installed and running on our Solaris systems. This business of allowing the password to be obtained either from the stack or the user was one of the problems I, too, encountered. Fixing it required some radical surgery to "pam_cracklib". One of the problems was that it didn't recognise the "use_first_pass" and "try_first_pass" conventions (options). I eventually got it working, including considerable tidying up and recognising those conventions. My tidying up also tried to abstract the handling of those options, and a couple of other things, so that other modules could share common code for such shared functionality. But because this was a non-trivial change, and because it had implications for the overall "make" mechanism (some of these implications are now fixed), these structural changes never made it to the Linux-PAM distribution. (A couple of the trivial ones made it, and some of the "make" ones. But, sadly, not these more major ones.) So yes, a solution to those "pam_cracklib" problems is possible. I hope that what I did could contribute towards it (at least in principle, even if my code isn't perfect...). -- : David Lee I.T. Service : : Systems Programmer Computer Centre : : University of Durham : : http://www.dur.ac.uk/t.d.lee/ South Road : : Durham : : Phone: +44 191 374 2882 U.K. :
