PAM merge from FreeBSD

[Frank Cusack]

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