From owner-freebsd-current Tue Nov 14 3:54: 5 2000 Delivered-To: freebsd-current@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id CCAE237B479; Tue, 14 Nov 2000 03:54:00 -0800 (PST) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.8.7/8.8.7) with ESMTP id WAA09436; Tue, 14 Nov 2000 22:53:56 +1100 Date: Tue, 14 Nov 2000 22:54:50 +1100 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: "John W. De Boskey" Cc: Current List Subject: Re: getty bug when run by hand In-Reply-To: <20001113190020.A98362@FreeBSD.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 13 Nov 2000, John W. De Boskey wrote: > When the following command is run as root: > > /usr/obj/usr/src/libexec/getty/getty std.38400 ttyd1 > > the call to login_tty() fails in the opentty() function: > > else { > login_tty(i); > return 1; > } > > However, the return code is not checked. File descripters 0, > 1, and 2 are not modified to point at ttyd1, and the getty then > proceeds to run on the current terminal session. > > At a minimum, I'd like to commit the following patch. It would > have helped avoid some frustrating moments... > > =================================================================== > RCS file: /home/ncvs/src/libexec/getty/main.c,v > retrieving revision 1.31 > diff -u -r1.31 main.c > --- main.c 2000/10/10 01:53:00 1.31 > +++ main.c 2000/11/14 02:25:31 > @@ -444,7 +444,10 @@ > return 0; > } > else { > - login_tty(i); > + if (login_tty(i) < 0) { > + syslog(LOG_ERR, "login_tty %s: %m", ttyn); > + return 0; > + } > return 1; > } > } This needs a "close(i);" for the error case. > This of course then leads to the question of why the > TIOCSCTTY ioctl call failes. From the above change: > > Nov 13 17:25:47 mail getty[1236]: login_tty /dev/ttyd1: Operation not > permitted This is because the process isn't a session leader. It isn't a session leader because the setsid() call before the ioctl failed (and it wasn't a session leader before that). The result of the setsid() is ignored, which is correct if setsid() failed due to the process already being a session leader, but obfuscates the error otherwise. setsid() fails because the process is a process group leader. This is the normal environment for processes started from shells. Session, process group and controlling terminal stuff is all set up for normal job control, and is difficult of impossible to change except in a new process. getty works when it is started from init because init doesn't do much setup for getty. It only sets up a controlling terminal for running /etc/rc and for single user mode... Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message