New PAM code landing (at last)

[Damien Miller]

Frank Cusack wrote:
>> Warning: this is a large change and will probably break things. It has
>> only been tested with basic password auth modules and not at all (by me)
>> on non-Linux systems (I put out test requests on snapshots of this, but
>> nobody responded...)
> 
> Actually, I did respond, and we got into an argument about it.  Although,
> I didn't have an opportunity to actually test it, and I guess no one
> else did either.

Well, tester responses were what I was after and, to set the record
straight, Darren Tucker and Kevin Steves responded.

> 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.

> I tried to download, but the latest snapshot (20030409) doesn't contain
> the PAM bits, and anoncvs.be.openbsd.org appears to be down.  

The mirrors may be slow to update, but 20030510+ should have the changes.

> I took some
> time to look at the snapshot you offered previously (20030123) and found
> three problems:
> 
> - kbdint authentication cannot be abandoned

I think that this has been rectified since the earlier snapshots.

> - 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.

> As to pam_*_session(), in this new code, the auth bits run in the
> monitor and communicate with the unpriv child via a socket.  Seeing
> that, I assumed pam_*_session() would have been setup to do the same.
> The problem seems pretty easy now that the plumbing is in place.

Actually, it isn't that simple. The PAM conversation runs in a
subprocess, to avoid its idiotic blocking nature. Therefore any side
effects of the pam_session call will be lost.

I have heard that at least some versions of PAM support a non-blocking
conversation. If so, I would be interested in seeing patches to support it.

Supporting pam_session as root, privsep and multiple sessions over one
protcol 2 connection is tricky. However, we could do a slightly crippled
version, where we call pam_session with no tty post-auth, before we
discard privs [in sshd.c:privsep_postauth()]. I don't know how many
pam_sesion modules that people use care about the tty, but since most of
the requests for this come from people using pam_limits and chroot
modules, I expect not many...

-d