I'm still fumbling my way through the lsh code and figuring out the
sequence of events when a new connection arrives (is there a way to
prevent the client and server from timing out when you're stepping through
the server code in gdb?).
As pertains to the allocation of pseudo-terminals, the sequence appears to
be this:
1. Connection arrives
2. Server allocates master and slave ptys.
3. Server forks a child to handle the host activities.
4. Child assumes identity of user.
Is there another fork between 2 and 3, or does the main lshd handle
ongoing connections? At what point does authentication take place?
It would seem necessary for the server to have the user's uid as its real
uid when grantpt is called in the SVR4 realm. I don't know about other
OS's, but according to the grantpt man page under Solaris 2.6, grantpt
sets the permissions according to the caller's _real_ uid, which would
seem to eliminate the possibility of calling seteuid to the user's id
before grantpt, then returning to root as effective uid. Looking at the
Unix98 specs, this seems to be the same for all compliant systems.
Generally, it would seem simplest to fork a child to handle the
connection. That child could then assume the user's identity before
allocating the ptys and forking again.
If the goal is to maintain all connection-handling in the main lshd
instance, I'm at a loss for ideas for working around the grantpt problem.
-John Daily
