From 581f693b276ca7ea11bf3d8d4281442e284acb21 Mon Sep 17 00:00:00 2001 From: Theodore Tso Date: Fri, 1 Dec 1995 22:35:35 +0000 Subject: [PATCH] Applied patch from Scott Schwartz 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. git-svn-id: svn://anonsvn.mit.edu/krb5/trunk@7154 dc483132-0cff-0310-8789-dd5450dbe970 --- src/appl/bsd/ChangeLog | 26 ++++++++++++++++++++++++++ src/appl/bsd/login.c | 41 +++++++++++++++++++++++++++++++++++++++++ 2 files changed, 67 insertions(+) diff --git a/src/appl/bsd/ChangeLog b/src/appl/bsd/ChangeLog index 74119d64a..9f3989343 100644 --- a/src/appl/bsd/ChangeLog +++ b/src/appl/bsd/ChangeLog @@ -1,3 +1,29 @@ +Fri Dec 1 17:25:02 1995 Theodore Y. Ts'o + + * login.c (main, dofork): Applied patch from Scott Schwartz + + + 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. + Sun Nov 12 12:39:23 1995 Sam Hartman * krlogind.c (doit): Clear iextn for NetBSD and other 4.4-based diff --git a/src/appl/bsd/login.c b/src/appl/bsd/login.c index 2f7456379..536d2bd30 100644 --- a/src/appl/bsd/login.c +++ b/src/appl/bsd/login.c @@ -813,6 +813,31 @@ bad_login: #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); @@ -1382,6 +1407,22 @@ dofork() 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... */ -- 2.26.2