New PAM code landing (at last)

[Frank Cusack]

On Mon, May 12, 2003 at 05:35:00PM +1000, Damien Miller wrote:
> Frank Cusack wrote:
> 
> > I don't see what's wrong with the existing code.  Especially when you
> > say the new code "will probably break things".  Now I have to study
> > this new code and port my bugfixes all over again. :-)
> 
> The current PAM kdb-int code is obviously broken, the current PAM
> password auth code only works by making AssUMeptions about the requests
> that PAM is going to make in the conversation function.

ALL (new & old) PAM password auth code must make assumptions; PAM and
password auth just aren't 100% compatible.  I don't see any major broken-
ness with the current PAM kbd-int code; nothing so egregious it requires
a complete rewrite anyway.

> > - print_pam_messages() doesn't do anything!
> > - sshpam_query() sends the client only one pam prompt at a time;
> >   this is explicitly mentioned as wrong in the kbdint draft.
> 
> I don't think so - we fill out our reply with as many messages as PAM
> returns to us, if it does it is an error higher up in out kbd-int
> support or in the PAM code itself.

No, you return only one message (at a time) from the conversation to
the client.  See auth2-chall.c:send_userauth_info_request() and
auth-pam.c:sshpam_query().

Specifically, sshpam_query() returns immediately on receipt of a PAM
message (from the PAM "thread") requiring interaction.  (auth-pam.c:373)
And sshpam_respond() explicitly looks for only one response.

Also, send_userauth_info_response() calls back into
send_userauth_info_request() until the exchange is complete; this doesn't
seem very elegant.  It holds the ssh client/server exchange hostage,
which IIRC was one of the things you (openssh guys in general) don't
like about the existing PAM code.  (I think you just can't get around that.)

Does the new code fork off a new process just to handle the PAM bits?
Looks that way.  What is the point?  You still have to be in lockstep
with the PAM conversation.

/fc