PAM merge from FreeBSD

[Nicolas Williams]

A few things to keep in mind:

 - kbd-int should call pam_authenticate(), acct_mgmt(), chauthtok(), if
   required, setcred(PAM_ESTABLISH_CRED) and open_session() ALL during
   kbd-int so that modules in each of those PAM stacks can prompt the
   user (pam_open_session(), for example, may prompt a user with an
   informational message akin to the last login message)

 - all userauth methods should call pam_acct_mgmt() and force kbd-int,
   via partial userauth failure, if pam_acct_mgmt() returns
   PAM_NEW_AUTHTOK_REQD (password expired)

 - pam_setcred(PAM_ESTABLISH_CRED) and pam_open_session() should be
   called by the end of userauth, regardless of which method(s) is(are)
   tried by the client and completed successfully. (NOTE: there's no tty
   at that point, nor any way to know if the client will want a tty
   session)

 - userauth methods other than kbd-int should have a null conversation
   function (either NULL, literally, or a function that returns
   PAM_CONV_ERR if any echo on/off prompts are issued)

 - all of those PAM calls have to be done in a process which is an
   ancestor to the user's actual session processes and those user
   processes should not be created before calling PAM either

 - preferably the process that calls pam_open_session() should be the
   one to call pam_close_session(), on the same PAM handle on which
   pam_open_session() was called

 - no concurrence (threads) is needed for any of this, but because of
   the way PAM conversations work

    - the event loop must be nested (yes, this is workable, and 3.5p1
      does nest the event loop in kbd-int userauth w/ PAM)

    OR

    - the PAM calls must be performed on alternative stacks (i.e., in a
      different co-process)

    OR

    - the server must packet_disconnect() rather than allow kbd-int to
      be abandoned or restarted

As Frank points out, multi-round-trip userauth methods can be
"abandoned" or "restarted" by the client; for kbd-int userauth this
means that multiple PAM conversations may be active, waiting for
responses, concurrently (but only the last one started can succeed -
the others must be either fail or be left waiting for responses that
will never come).

Cheers,

Nico
-- 

On Wednesday, February 26, 2003, Frank Cusack wrote:
> On Sun, Feb 02, 2003 at 01:48:52PM +0100, Dag-Erling Smorgrav wrote:
> > My code runs the PAM authentication in a separate thread or process to
> > avoid calling the main loop from the conversation function (which
> > won't work with privsep anyway).  Modules like pam_krb5 where the
> > session management stage uses information stored by the authentication
> > stage only work when using threads, because threads can share a PAM
> > handle but processes can't.
> 
> Here are my initial thoughts.
> 
> The PAM stuff runs in the priv part.  You communicate to the unpriv part
> via a socket.  Why bother with threads?  The thread is just an added
> complication.  OK, it avoids having to grab control of the main loop
> from within the conversation function, but I just wonder if there's
> another way to do this.  I mean, you're still stuck in the conv.
> function until the info response comes back, anyway.  How do (will)
> you handle restarting the authentication (client sends USERAUTH_REQUEST
> instead of USERAUTH_INFO_RESPONSE)?
> 
> In auth-pam.c:sshpam_thread_conv(), line 148, the two cases ECHO_OFF and
> ECHO_ON should be combined into a single case, as should the ERROR_MSG
> and TEXT_INFO cases; just as you do in sshpam_query().
> 
> The code as a whole /is/ far cleaner than what exists currently, so that
> is a big plus.
> 
> I dislike that kbdint is run via auth2_challenge() and all the refs
> to "challenge".  It's not necessarily a challenge.
> 
> /fc