openssh unix dev - Aug 2002 - Tru64 privsep patch testing

OK, I got a chance to try out the Tru64 patch for privsep. I applied the patch
to 3.4p1. Partial success, in that it now works for me for logins to
"root".
Logins to ordinary accounts fail after authentication, when trying to set tty
characteristics. See the excerpt from the debug messages below. This is for
Tru64 V4.0F (with enhanced_security turned on, obviously.) I guess it's time
to dive into the code...

[--- debug transcript ---]
debug1: server_input_channel_req: channel 0 request x11-req reply 0
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req x11-req
debug1: fd 13 setting O_NONBLOCK
debug2: fd 13 is O_NONBLOCK
debug1: channel 1: new [X11 inet listener]
debug1: server_input_channel_req: channel 0 request shell reply 0
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req shell
debug1: fd 4 setting TCP_NODELAY
debug1: channel 0: rfd 12 isatty
debug1: fd 12 setting O_NONBLOCK
debug2: fd 11 is O_NONBLOCK
debug1: Setting controlling tty using TIOCSCTTY.
debug3: : tty /dev/ttyp2 ptyfd 7
debug3:  entering
debug3: : checking request 38
Error in terminal setup.

Couldn't establish session for dhp from xxxx.phy.anl.gov
debug1: Calling cleanup 0x12004fb60(0x140031218)
debug1: session_pty_cleanup: session 0 release /dev/ttyp2
[--- end ---]

On Wed, 28 Aug 2002, David Potterveld wrote:

  > Tru64 V4.0F (with enhanced_security turned on, obviously.) I guess
it's time
  > to dive into the code...
  >

For some reason under 4.0F the function names don't show up in the debug3
messages
 
  > debug3: : tty /dev/ttyp2 ptyfd 7
  > debug3:  entering
  > debug3: : checking request 38
  > Error in terminal setup.
  > 
  > Couldn't establish session for dhp from xxxx.phy.anl.gov
  > debug1: Calling cleanup 0x12004fb60(0x140031218)
  > 

Here they are from my 5.1A attempt:

     debug3: mm_answer_pty: tty /dev/pts/2 ptyfd 4
     debug3: mm_request_receive entering
     debug3: monitor_read: checking request 38
     Error in terminal setup.
     
     Couldn't establish session for harbaugh from ncihp1.ncifcrf.gov
     debug1: Calling cleanup 0x120055cac(0x140031cc8)

-----------------------------------------------------------------------
Toni Harbaugh-Blackford                     harbaugh at nciaxp.ncifcrf.gov
AlphaServer 8400 System Administrator
SAIC/NCI Frederick Advanced Biomedical Computing Center

Hi,

I can use gcc for debugging. I still prefer decc for production for various
reasons, including performance. I've traced the problem to an error return
from sia_ses_estab called by setup_sia in auth-sia.c.
I'm still investigating...

David Potterveld

Further news: the Tru64 privsep problem seems to be a clash between the
privileged and unprivileged processes, with both attempting to launch sia
sessions on the same (pseudo-)terminal. When I run the privileged process
in a debugger, with a breakpoint early in sia_setup, and then try to connect
with a client, the damn thing works. The privileged process stops at the
breakpoint, the unprivileged child forges ahead, and the client completes
the connection. I get a shell, and everything seems OK. X11 forwarding works
as well. Examining the data back in the parent, in the context of sia_setup,
I see it wants to launch a session on the same tty. The sia_ses_estab call
fails, and the parent exits, which brings down the working client session.

The next step for me is to try and figure out what the correct sequence of
sia calls from both priv and unpriv perspectives *should* be, and then how
to untangle them.

David Potterveld

I assume you are going against --current or a more recent snapshot.

The patch was never designed to be applied again 3.4p1 tree.  All testing
was done on --current.

- Ben

On Thu, 29 Aug 2002, David Potterveld wrote:
> Further news: the Tru64 privsep problem seems to be a clash between the
> privileged and unprivileged processes, with both attempting to launch sia
> sessions on the same (pseudo-)terminal. When I run the privileged process
> in a debugger, with a breakpoint early in sia_setup, and then try to
connect
> with a client, the damn thing works. The privileged process stops at the
> breakpoint, the unprivileged child forges ahead, and the client completes
> the connection. I get a shell, and everything seems OK. X11 forwarding
works
> as well. Examining the data back in the parent, in the context of
sia_setup,
> I see it wants to launch a session on the same tty. The sia_ses_estab call
> fails, and the parent exits, which brings down the working client session.
>
> The next step for me is to try and figure out what the correct sequence of
> sia calls from both priv and unpriv perspectives *should* be, and then how
> to untangle them.
>
> David Potterveld
>
> _______________________________________________
> openssh-unix-dev at mindrot.org mailing list
> http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
>

Hi Ben,
> I assume you are going against --current or a more recent snapshot.
Well, I was using 3.4p1. I just downloaded, patched, and built the
20020826 snapshot. This does behave differently... I ran sshd interactively
(sshd -e -d -d -d) and tried to connect with a client. The privileged process
commits the same error as before. The difference is that now it doesn't
tear down the client session when it exits, and the client appears functional
(warning: not tested yet beyond simply getting a shell.) So it seems to me that
there is still something wrong in the logic: at this point, the privileged
process shouldn't be trying to launch another session on this tty, and it
just happens to work now because the unprivileged process is better isolated.

Toni: Thanks for researching how to build the snapshot (and everyone else for
responding)!

David Potterveld
Argonne National Laboratory