Nicolas Williams wrote: > > Indeed, it's not very pretty to try to save the password from the > conversation function, but it is a workaround, and it is portable. Surely, one could modify the pam_unix module to do this too..? (You could make it selectable with a module argument and cache the password in a pam_[gs]et_data() item.) > Just save all the no echo prompts' returns and try each in succession > as the old authtok till pam_chauthtok() succeeds or all of those tokens > fail. [Please, no more hacks in the conversation function!] > But yes, I too have been mystified by a few silly things in PAM: > > - Why not allow the app to save the authtok? After all it has done the > prompting, so it oissesse the authtoks, just not in a convenient way In the grand scheme of things, PAM was supposed to remove the need for applications to know about passwords at all. Not allowing apps to get/set them from PAM was a design decision - all this info was supposed to be something that a module managed. Reality is that some applications have very bad legacy problems - authentication hardwired into their communication protocol etc., but login is not one of them. > - Why not allow pam_authenticate() to return PAM_NEWAUTHOTK_REQD? This > can't be changed backwards compatibly now without also adding a new > API by which an app may indicate to PAM which version of PAM it > supports. I guess its not clear to me why the existing account management stuff isn't good enough for this? Cheers Andrew
