[6502] in Kerberos
Re: SIGINT in the rlogind child
daemon@ATHENA.MIT.EDU (Sam Hartman)
Fri Jan 19 11:37:00 1996
Date: Fri, 19 Jan 1996 11:06:17 -0500
From: Sam Hartman <hartmans@MIT.EDU>
To: Sam Hartman <hartmans@MIT.EDU>
Cc: Gary Gaskell <gaskell@dstc.edu.au>, kerberos@MIT.EDU, krb5-bugs@MIT.EDU
In-Reply-To: "[1726] in Kerberos-V5-bugs"
>>>>> "Sam" == Sam Hartman <hartmans@MIT.EDU> writes:
>>>>> "Gary" == Gary Gaskell <gaskell@dstc.edu.au> writes:
Gary> Version details: V5 beta 5 on DEC OSF/1 v 3.2 Background:
Gary> Using kerbersied rlogin to secure connections between
Gary> research labs on different university campuses. Some users
Gary> complained that a ^C on the rlogin client caused the rlogin
Gary> session itself to abort, rather than just to kill some
Gary> process they were running on the remote computer.
Sam> I would be interested in which operating systems this
Sam> happens on. I know it happens on SunOS, Solaris, and now
Sam> OSF.
Gary> SIGINT is ignored in the client, but the ^C is sent to the
Gary> server, where it kills the child. This kills the session,
Gary> and the client reports "Connection Closed".
OK, I've finally figured out what was going on. Basically,
there were at least two problems (although I suspect a major rewrite
of terminal handling fixed several more) that appear when you hit
ctrl-c. Once the server-side problems with login.krb5 and the child
were fixed, you were left with a Solaris (and possibly SGI--we're
still porting to SGI, so it doesn't quite work yet) client bug. The
SIGURG handling in the client is incredibly broken; I'm still not sure
I understand how it ever worked.Among other things, it used read
instead of des_read, and despite comments in the code, couldn't be
called when there wasn't actually out-of-band data. Normally, the
server sends a flush (out-of-band) when it gets a ^c. Under Solaris
this appears to be enough to cause the session to lock up, waiting for
oob data that isn't coming because of another client bug that doubles
the number of delivered SIGURG signals.
The really broken part of all this is that a simple select
works quite as well as the complicated mess of signal handlers in the
client; the next release will contain this fix. I tried to generate a
patch against beta5, but there have been too many changes in krlogin.c
to make it practical.
Sam> This confuses me. The krlogind child shouldn't exist
Sam> any more as it should have been replaced by the shell. If
Sam> you mean it kills krlogind, then that's really puzzling
Sam> (although I think that is probably what is happening),
Sam> because krlogind should not be in the foreground process
Sam> group of that tty. I would appreciate any comments
Sam> explaining what's happening; I haven't had time to really
Sam> track down the problem, although I will eventually get to it
Sam> if no one else knows what is failing.
Gary> So I got into krlogind.c and in the child , told it to
Gary> ignore any SIGINT signals.
Gary> The question: Any reason why this should not be done?
Sam> If it fixes your problem and you aren't interested in
Sam> finding the real bug, this is a quick fix. This may end up
Sam> being the right solution, but I am reluctant to make this
Sam> change to our source tree until I understand what process is
Sam> getting killed, and why it gets the sigint signal. It is my
Sam> understanding that most shells ignore sigint so I'm not sure
Sam> I see what is happening unless krlogind itself is getting the
Sam> kill signal. If this is the case, I am really confused,
Sam> because as I said above, it should be in the wrong process
Sam> group.
This change doesn't hurt, but where it really needs to be
fixed is in login.c, which sticks around to destroy tickets (although
this functionality isn't fully implemented). It was getting the
sigINT and was being killed, inadvertantly killing the session. Our
login currently ignores SIGINT after it forks to run the shell.
Sam> Again, this is a rather annoying problem, and we will
Sam> fix it; this bug as well as SunOS utmp handling is at the top
Sam> of my to-do list for telnetd and krlogind.
BTW, I believe I have fixed the utmp handling for Sunos,
Ultrix and Solaris. The utmp handling on AIX, Linux and NetBSD (while
broken in beta5) was already fixed. I currently don't have a test
ALPHA/OSF machine (although I should have one again soon), I believe
the OSF utmp handling also will work now. I will be testing SGI soon.
--Sam
Sam> --Sam --[1726]--
