From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/6422 Path: news.gmane.org!not-for-mail From: Felix Janda Newsgroups: gmane.linux.lib.musl.general Subject: Re: Add login_tty Date: Sat, 1 Nov 2014 23:56:43 +0100 Message-ID: <20141101225643.GA8817@euler> References: <20140825185756.GA6077@euler> <20140825224333.GX12888@brightrain.aerifal.cx> <20140826165627.GA1208@euler> <20141031161907.GD22465@brightrain.aerifal.cx> <20141101211523.GA13145@euler> <20141101214503.GK22465@brightrain.aerifal.cx> <20141101222729.GB5949@euler> <20141101224325.GM22465@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1414882642 30966 80.91.229.3 (1 Nov 2014 22:57:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 1 Nov 2014 22:57:22 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-6435-gllmg-musl=m.gmane.org@lists.openwall.com Sat Nov 01 23:57:15 2014 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1Xkhbf-0008He-Ip for gllmg-musl@m.gmane.org; Sat, 01 Nov 2014 23:57:15 +0100 Original-Received: (qmail 22042 invoked by uid 550); 1 Nov 2014 22:57:13 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 22030 invoked from network); 1 Nov 2014 22:57:12 -0000 X-Virus-Scanned: amavisd-new at posteo.de Mail-Followup-To: musl@lists.openwall.com Content-Disposition: inline In-Reply-To: <20141101224325.GM22465@brightrain.aerifal.cx> User-Agent: Mutt/1.5.22 (2013-10-16) Xref: news.gmane.org gmane.linux.lib.musl.general:6422 Archived-At: Rich Felker wrote: > One more issue: > > On Sat, Nov 01, 2014 at 11:27:29PM +0100, Felix Janda wrote: > > int forkpty(int *m, char *name, const struct termios *tio, const struct winsize *ws) > > { > > @@ -13,12 +12,7 @@ int forkpty(int *m, char *name, const struct termios *tio, const struct winsize > > pid = fork(); > > if (!pid) { > > close(*m); > > - setsid(); > > - ioctl(s, TIOCSCTTY, (char *)0); > > - dup2(s, 0); > > - dup2(s, 1); > > - dup2(s, 2); > > - if (s>2) close(s); > > + login_tty(s); > > Here there's no checking for failure of login_tty. Note that checking > for failure would not be useful, because there's no valid response, > but: > > > diff --git a/src/misc/login_tty.c b/src/misc/login_tty.c > > new file mode 100644 > > index 0000000..f0be0a0 > > --- /dev/null > > +++ b/src/misc/login_tty.c > > @@ -0,0 +1,14 @@ > > +#include > > +#include > > +#include > > + > > +int login_tty(int fd) > > +{ > > + setsid(); > > + if (ioctl(fd, TIOCSCTTY, (char *)0)) return -1; > > + dup2(fd, 0); > > + dup2(fd, 1); > > + dup2(fd, 2); > > + if (fd>2) close(fd); > > + return 0; > > +} > > Unlike the code moved out of forkpty, this code errors out early if > the ioctl fails, thereby skipping the dup2's and close. In the case of > forkpty, this leaves the child process in a very messed-up state with > regard to its file descriptors; it will clobber the parent's > stdin/out/err without knowing anything is wrong. > > In the case of forkpty, the error just needs to be ignored, I think, > like it is now. I'm not sure what login_tty should do, though. > Reporting the error is good, but leaving the process and its file > descriptors in an unpredictable state is not good. Is there any > documentation for how they're left on error? I have taken from the man page that if the ioctl fails login_tty will also fail. So how about int login_tty(int fd) { int ret; setsid(); ret = ioctl(fd, TIOCSCTTY, (char *)0); dup2(fd, 0); dup2(fd, 1); dup2(fd, 2); if (fd>2) close(fd); return ret; } Felix