also needed for Tru64 SIA to work in privsep. WAS: Passwordexpirypatch plans

Darren Tucker dtucker at zip.com.au
Tue Nov 19 00:29:27 EST 2002


Michael Steffens wrote:
> > 1) Slave calls wrapped chauthtok, request passed to monitor
> > 2) Monitor allocs pty, opens, makes controlling tty
> > 3) Monitor passes descriptors back to slave
> > 4) Monitor calls chauthtok / SIA / whatever
> > 5) Slave spins copying to and from stdio and the passed fd's
> > 6) In monitor, chauthtok returns and returns status to slave
> > 7) Slave reads return status from monitor
> 
> Sounds very good to me. But 5) seems to be the tough point
> (where actually my brain got spinning :)
>
> How to avoid communication monitor <-> slave and
> slave <-> network socket blocking each other? The
> latter one will need to be served for the remote client
> to see the communication in any case.

I was thinking of during the session (ie where chauthtok is now) and SIA
(about which I know nothing except the contents of the previous
message).

You could select() on the 2 readable fds? Given the challenge-response
nature of PAM, it's likely to be half-duplex anyway.

It doesn't (easily) handle the keyboard-interactive + privsep case. You
could wrap a simple protocol around it (eg ^D = end of message or
something) for that but that might be ugly.

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.



More information about the openssh-unix-dev mailing list