[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Bug in handling of AUTHTOK item

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

Also, the application provides the conversation function, so the
application will see the tokens anyways, so why deny it access to those

> 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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index] []