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

Re: Asynchronous PAM - long post



Scott,

This is already implemented in the Linux-PAM library. The conversation
function needs to return PAM_CONV_AGAIN, and the module needs to
acknowledge this by returning PAM_INCOMPLETE to the application. libpam
(Linux-PAM) supports this transition and restarting the module stack at
the place that returned this way. 

This event driven authentication mode requires compliance by the module
(it needs to save state and wakeup in the right way) and by definition
the application needs to know about it, but then it did supply the
conversation function! The basic sequence is:

  pam_authenticate
    pam_sm_authenticate
      conversation() -> PAM_CONV_AGAIN (no replies are returned yet)
    -> PAM_INCOMPLETE
  [application 'waits' for conversation to complete]
  pam_authenticate
    [libpam resumes from at the module that returned PAM_INCOMPLETE]
    pam_sm_authenticate
      [the module calls the conversation with identical message(s) to
last time]
      conversation() -> PAM_SUCCESS (with all of the responses)
    [.... continue down the module stack ....]
  -> PAM_SUCCESS (etc..)

At this time, I believe only pam_pwdb and a couple of more simple (tar
bundled) modules support this convention. The password changing support
in pam_pwdb may not be complete - I was lacking a suitable test bench to
do/test it so its still in the air.

I believe this is what you want so I hope this info helps.

Cheers

Andrew

> Scott Rachels wrote:
> 
> Does or WILL pam support an asyncronous authentication process? Any
> suggestions or workarounds for now? It would help me use PAM on a
> single process/single threaded server that handles multiple clients
> (using select).
> 
> Right now it seems on pam_authenticate(), the server must always block
> in the conversation function waiting for user input because the
> modules expect responses from the conversation.
> 
> One idea would be to have the conversation function write the prompt
> to a socket and return PAM_CONV_CONTINUE. This allows the conversation
> and the module to save the state and allows the pam engine to remember
> where it was in the module chain.
> 
> When a response comes back on the socket for the prompt, the server
> application calls pam_conv_continue(pamh, my_conv), which forwards the
> call to the module that received the PAM_CONV_CONTINUE. That module
> then calls the conversation function again with the received response
> data (from the socket). The conversation functions put the responses
> into the response array and returns PAM_SUCCESS.
> 
> Here is a sample call path:
> 
> Client:
> ------
>     <<request auth from server>>
> 
> Server:
> ------
> pam_authenticate(pamh,user,flags,auth_cb);
>    pam_sm_authenticate(...);
>       conv->conv(num,msgs,resps,data);
>           <<create packet from msgs>>
>           <<send packet to client>>
>           return PAM_CONV_CONTINUTE;
>       pamh->continue_with_which_module = this_module;
> 
> 
> Client:
> ------
>    << receive request from server for pam responses >>
>    << get responses from user, from libpamc interface, whatever...>>
>    << send packet with responses to server >>
> 
> Server:
> ------
> select(...)
> <<received response from client>>
> pam_conv_continue(pamh, response);
>    << use module pointed to by pamh->continue_with_which_module >>
>    pam_sm_conv_continue(response);
>       << put response into msgs with PAM_CONV_CONTINUE msg type >>
>       conv->conv(num,msgs,resps,data)
>          case PAM_CONV_CONTINUE:
>             << put msgs into resps >>
>             return PAM_SUCCESS
>       <<authenticate with resps>>
>       return PAM_SUCCESS;
>    auth_cb(); // cb passed in initial pam_authenticate()
> 
> Thanks for looking at this. Any guidance would be very much
> appreciated.
>



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