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

[David Potterveld]

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