[6256] in Kerberos
Re: SIGINT in the rlogind child
daemon@ATHENA.MIT.EDU (Scott Schwartz)
Sat Nov 18 14:28:46 1995
To: kerberos@MIT.EDU
Date: 18 Nov 1995 18:56:27 GMT
From: schwartz@galapagos.cse.psu.edu (Scott Schwartz)
hartmans@MIT.EDU (Sam Hartman) writes:
| If it fixes your problem and you aren't interested in finding
| the real bug, this is a quick fix.
The real bug is that kerberos doesn't do process groups correctly in
sunos. I've submitted bug reports on the topic a number of times in
the past; in case anyone cares, here's the patch I suggested. (It
would be simpler without the login.krb5 thing getting in the way.)
To: krb5-bugs@athena.mit.edu
Subject: rlogin/telnet bugs and controlling ttys under SunOS
Date: Mon, 08 May 1995 15:42:49 -0400
From: Scott Schwartz <schwartz@galapagos.cse.psu.edu>
[This obsoletes a patch I submitted for beta 4.]
Under SunOS, and maybe other systems, there is a a problem with
krlogind.c and a similar problem with login.c as distributed with
K5.5.
The bug is that rlogind forks a child but retains a controlling tty.
If the child is in the same process group as the parent, which is will
if you don't use a job control shell (chsh /bin/rc), keyboard signals
will kill the daemon. telnetd dissociates itself properly, but then
login.krb5 waits for the shell to finish, but login.krb5 has the same
ctty as the shell and is in the same process group, so it has the same
problem.
In BSD you used to be able to give up your ctty at will, but SunOS
seems to have setsid as the only mechanism to perform that action, and
setsid can only succeed in limited circumstances. Rlogind ought to be
fixed to behave more like telnetd, but independent of that, login.krb5
needs to be patched if kerberos is to work properly under SunOS. With
the following change to appl/bsd/login.c, rlogin and telnet seem to
work reliably:
*** 1.1 1995/05/07 06:23:52
--- login.c 1995/05/07 21:22:40
***************
*** 800,805 ****
--- 800,830 ----
#endif
/* Fork so that we can call kdestroy */
dofork();
+
+ /* If the user's shell does not do job control we should put it in a
+ different process group than than us, and set the tty process group
+ to match, otherwise stray signals may be delivered to login.krb5 or
+ telnetd or rlogind if they don't properly detach from their
+ controlling tty, which is the case (under SunOS at least.) */
+
+ { int p = getpid();
+ if (setpgrp(p,p) < 0) perror("login.krb5: setpgrp");
+ if (ioctl(0, TIOCSPGRP, &p) < 0) perror("login.krb5: tiocspgrp");
+ }
+
+ /* SunOS has an ioctl which can set the controlling tty and make sure
+ that no other process also has it. That's exactly what we want to
+ do for the shell we are about to exec, since it is the documented
+ way to avoid the problem noted just above. */
+
+ #ifdef sun
+ #ifdef TIOCSCTTY
+ { if (setsid() < 0) perror("login.krb5: setsid");
+ if (ioctl(0, TIOCSCTTY, 1) < 0) perror("login.krb5: tiocsctty");
+ }
+ #endif
+ #endif
+
#endif /* KRB4 */
(void)setgid((gid_t) pwd->pw_gid);
(void) initgroups(username, pwd->pw_gid);
***************
*** 1362,1367 ****
--- 1387,1408 ----
#endif
if(!(child=fork()))
return; /* Child process */
+
+ { /* Try and get rid of our controlling tty. On SunOS, this may or may
+ not work depending on if our parent did a setsid before exec-ing us. */
+ #ifdef TIOCNOTTY
+ { int fd;
+ if ((fd = open("/dev/tty", O_RDWR)) >= 0) {
+ ioctl(fd, TIOCNOTTY, 0);
+ close(fd);
+ }
+ }
+ #endif
+ #ifdef HAVE_SETSID
+ (void)setsid();
+ #endif
+ (void)setpgrp(0, 0);
+ }
/* Setup stuff? This would be things we could do in parallel with login */
(void) chdir("/"); /* Let's not keep the fs busy... */
