John Daily <[EMAIL PROTECTED]> writes:
> 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?).
I'm not aware of any timeouts (except for those inside the tcp
implementation...). A good place to start stepping may be the
handle_connection() function in connection.c. It gets control after
each packet is decrypted, and before the packet-type dispatch. You may
also want to contemplate the ssh-2 specifications to get another view
on the sequence of events.
> 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?
User authentication happens between 1 and 2. There's no forking until
the client's shell-request is processed, i.e. in step 3 above.
> 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.
That seems like a serious problem.
> 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.
I have considered implementing an option to fork and change uid
immediately after user authentication. Although that's a little tricky
to get right. I don't want to fork any earlier than that.
> 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.
As I see it, there are a few alternatives:
× Delay the call to grantpt until the child shell is being spawned.
One problem is that in order to report failed pty allocation to the
client, the reply to the client's pty request would have to be delayed
as well, which some clients may not like (but I think the next version
of lsh will handle it just fine).
× Forking one extra time immediately after successful user
authentication, as described above.
× Implement a better grantpt() function, which also takes a uid as
argument. After a first reading of the glibc implementation
(glibc-2.1.1pre1, available on ftp://alpha.gnu.org, in the file
sysdeps/unix/grantpt.c), it seems that this is a lot easier than one
might fear. First, note that the grantpt-with-uid function makes sense
only when the server runs as root (or else it can't change uid anyway,
so the standard grantpt is good enough). Therefore, no setuid helper
program or other permission trickery is needed. All the function has
to do is
get the name of the client pty,
stat it,
make sure that it is owned by the right uid,
make sure that it is owned by the tty group,
make sure that it is readable and writable by its owner, and
writable by its group.
Should be at most 50 lines of code. Do you think that would solve the
problem? Now I only have to figure out how to find the group id of the
tty group in a portable way.
Regards,
/Niels
