openssh unix dev - Feb 2002 - 3.0.2p1: all sshd processes owned by root

Hi,

   I installed 3.0.2p1 on our Solaris 8 systems this week (new to ssh),
and when I look at the process list for sshd, I see:

    root 14547     1  0 10:35:29 ?        0:00 /opt/openssh/sbin/sshd
    root 14548 14547  0 10:35:36 ?        0:01 /opt/openssh/sbin/sshd

Process 14547 is the deamon listening on port 22, but process 14548 is
my connection from elsewhere.  I consider it a design flaw (cough, bug)
that this process is owned by root and not by the user who made the
connection, eg:

    root 14547     1  0 10:35:29 ?        0:00 /opt/openssh/sbin/sshd
 joeblow 14548 14547  0 10:35:36 ?        0:01 /opt/openssh/sbin/sshd

So, I looked at the source code for sshd.  Why are there no setuid() and
setgid() calls in the code to change to the user, after the child process
is forked off to process the new connection?  It looks like the uid and
gid of the user should be known after do_authentication() or
do_authentication2() has been called, so the ownership of the forked
daemon could be changed after this point.  Why isn't it?

--- Jeff Earickson, Colby College

On Thu, 14 Feb 2002, Jeff A. Earickson wrote:
> Hi,
> 
>    I installed 3.0.2p1 on our Solaris 8 systems this week (new to ssh),
> and when I look at the process list for sshd, I see:
> 
>     root 14547     1  0 10:35:29 ?        0:00 /opt/openssh/sbin/sshd
>     root 14548 14547  0 10:35:36 ?        0:01 /opt/openssh/sbin/sshd
> 
> Process 14547 is the deamon listening on port 22, but process 14548 is
> my connection from elsewhere.  I consider it a design flaw (cough, bug)
> that this process is owned by root and not by the user who made the
> connection, eg:
> 
>     root 14547     1  0 10:35:29 ?        0:00 /opt/openssh/sbin/sshd
>  joeblow 14548 14547  0 10:35:36 ?        0:01 /opt/openssh/sbin/sshd
> 
> So, I looked at the source code for sshd.  Why are there no setuid() and
> setgid() calls in the code to change to the user, after the child process
> is forked off to process the new connection?  It looks like the uid and
> gid of the user should be known after do_authentication() or
> do_authentication2() has been called, so the ownership of the forked
> daemon could be changed after this point.  Why isn't it?
The server needs to be able to write logout entries to [uw]tmp and
lastlog, clean up pty's and keep a copy of the private host key for 
key renegotiation. 

-d