openssh unix dev - Aug 2002 - no, I see now, tru64 pty ownership wrong on entry to setup_sia, may need /usr/lbin/chgpt (WAS Re: Tru64 privsep patch testing)

Hi Toni,

I'm sorry, I haven't had much time to work on this today. When I run
sshd
(from the patched snapshot) in a debugger, with a breakpoint early in
setup_sia(), this is what I find after connecting with a client:

(1) There are two sshd processes. One is running as root, and the other
    as the user I logged with using the client. The root process is the
    one in the debugger, which I've been calling the privileged process,
    and the other one I called the unprivileged process. There is also
    a user process running a shell, connected to the client through a pty.

(2) The pty is owned by the user. On my system, for example:
    crw--w----   2 dhp      terminal   6,  3 Aug 30 17:05 /dev/ttyp3

Now, if I step through setup_sia() in the debugger, I get an error return
from sia_ses_estab(), so that fatal() is called, which results
session_pty_cleanup() being called, which resets the pty ownership back
to the default:

crw-rw-rw-   2 root     system     6,  3 Aug 30 17:05 /dev/ttyp3

This is the state you were finding things in. I suspect that what happens is,
the privileged process forks, sets up the pty, and becomes the user all on its
own, and then the privileged process starts doing the sia stuff. But its just a
suspicion... I need to read the code carefully myself to understand what's
happening.

David Potterveld
Argonne National Laboratory

Hi-

I've been going over various documentation I have on the sia routines,
and I think there is a fundamental problem that correcting terminal
characteristics won't fix.

I tried various manipulations of the file descriptors and open files
within the setup_sia routine and although I was able to get the
'Error in terminal setup' message to disappear the sia_ses_estab()
routine still failed.

On Fri, 30 Aug 2002, David Potterveld wrote:

  > (1) There are two sshd processes. One is running as root, and the other
  >     as the user I logged with using the client. The root process is the
  >     one in the debugger, which I've been calling the privileged
process,
  >     and the other one I called the unprivileged process. There is also
  >     a user process running a shell, connected to the client through a
pty.
  >
<... text deleted...>
  > 
  > Now, if I step through setup_sia() in the debugger, I get an error return
  > from sia_ses_estab(), so that fatal() is called, which results
  > session_pty_cleanup() being called, which resets the pty ownership back
  > to the default:
  > 
  > crw-rw-rw-   2 root     system     6,  3 Aug 30 17:05 /dev/ttyp3
  > 
  > This is the state you were finding things in. I suspect that what happens
is,
  > the privileged process forks, sets up the pty, and becomes the user all
on its
  > own, and then the privileged process starts doing the sia stuff.

Yes, and that is the fundamental problem.  From the documentation I've
seen, it does not appear that one process can set up a SIA session for
another process.  If a process needs a SIA session, it has to set up
the session itself as root, *then* become whoever it needs to be.
This is what happens when privsep is disabled.  When privsep is off,
do_child() is running as uid 0, and calls setup_sia() *directly* within
the same process.

It appears that the integration of the sia session setup will either
have to be rethought or abandoned in order for privsep to work.

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