On Tue, Jan 16, 2001 at 09:04:40AM -0800, Andrew Morgan wrote: > But this is not a bug. This is very much designed behavior. > > The whole point of PAM is that the modules drive authentication. Having > the application drive the authentication and then tell PAM what to do is > putting the cart before the horse. Why even bother calling > pam_authenticate()? Just because the application has the username and password before calling pam_authenticate() doesn't ruin the value of calling pam_authenticate(). Also, the application provides the conversation function, so the application will see the tokens anyways, so why deny it access to those tokens? > There are multiple ways to solve this problem. The most expedient one is > the hack that currently exists - make the conversation function provide > a cached password. A cleaner one involves using Solar Designer's > userpass module. Yes, you can make the conversation function do that. But you still have a problem, because a given AUTHTOK might be needed in functions other than pam_authenticate() (because of module-specific reasons, say), but the item is not preserved; how can the conversation function distinguish wether it's being prompted for an additional password or for the same initial password it has already returned? Also, the comments in the source indicate that the reason for the current handling of the PAM_*AUTHTOK items is that the XSSO spec says that the application shouldn't have access to them. That's one thing, but to not preserve the tokens across PAM calls is another. I think a change could be made such that pam_get_item() uses a flag in the pam_handle to determine wether it's being called by the application or by a module and acct accordingly. This flag would be set/unset when entering/exiting the pam_authenticate(), pam_acct_mgmt(), pam_setcred(), pam_open_session(), pam_close_session(), pam_chauthtok() and the converse support function. Thus preserving the spec semantics. > Cheers > > Andrew Nico --
