[6674] in Kerberos
Re: krlogin/krlogind usage of OOB data is broken
daemon@ATHENA.MIT.EDU (Sam Hartman)
Fri Feb 16 16:26:51 1996
To: Barry Jaspan <bjaspan@bbnplanet.com>
Cc: Tim Shepard <shep@ginger.lcs.mit.edu>, kerberos@MIT.EDU
From: hartmans@MIT.EDU (Sam Hartman)
Date: 16 Feb 1996 15:53:32 -0500
In-Reply-To: Barry Jaspan's message of Fri, 16 Feb 96 11:02:06 EST
>>>>> "Barry" == Barry Jaspan <bjaspan@bbnplanet.com> writes:
Barry> I would like to add a small comment to this thread. I'm
Barry> sure that OOB data handling with krlogin is broken. But I
Barry> do not believe that is the bug that causes ^C to kill the
Barry> session.
One bug? Why should a problem be caused by a single bug when
it can be caused by two or three? Seriously, see below for my current
best guess at what was happening with Beta5 rlogin; it is possible
that the OOB handling in Beta5 was more broken than in Beta3, but I
think it was probably similarly broken.
Barry> When I investigated this bug, I found that the real problem
Barry> was that rlogind was not disassociating itself from the
Barry> process group that included login and/or the user's shell.
Barry> Thus, when a user typed ^C to rlogin, it got sent to
Barry> rlogind, which wrote it to the pgrp's terminal, which
Barry> generated a SIGTERM for the process group. rlogind
Barry> receieved the signal because it was in the pgrp, so it
Barry> exited.
This certainly was the case. The calling of setsid() in
rlogind was done in the wrong place, in such a way that it might not
even work on some systems.
Barry> I recall that this was only a problem with one of sh or
Barry> csh, but not both, because those two shells handle pgrps
Barry> for their children differently; but I don't remember the
Barry> details.
I believe it would have been a problem for sh. So, if a user
had sh, they would drop the session after the the first ctrl-c.
However, if they had csh as a shell, they would experience the
OOB bug, especially with a Solaris rlogin client. Apparently, Solaris
was delivering more SIGURG signals than OOB packets, so after the
second or third ctrl-c, the client would try to read OOB data that
wasn't there. In this situation, the client code assumed it needed to
free up buffer space so the OOB data could be delivered, so it
continued to read(2) until it got OOB data. This caused the session
to lock up.
Barry> Fixing rlogind to create a new pgrp (typically with
Barry> setsid(), after closing the pty) for the user's shell fixed
Barry> the problem.
Barry> Barry
