mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <dalias@libc.org>
To: musl@lists.openwall.com
Subject: Re: Add login_tty
Date: Sat, 1 Nov 2014 20:09:44 -0400	[thread overview]
Message-ID: <20141102000944.GN22465@brightrain.aerifal.cx> (raw)
In-Reply-To: <20141101225643.GA8817@euler>

On Sat, Nov 01, 2014 at 11:56:43PM +0100, Felix Janda wrote:
> 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 <utmp.h>
> > > +#include <sys/ioctl.h>
> > > +#include <unistd.h>
> > > +
> > > +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

Yes, it documents this failure, but not the side effects on failure:

- Whether a new session has been created.
- Whether file descriptors 0-2 have been replaced.
- Whether fd has been closed.

This kind of lack of documentation is a big problem in duplicating
nonstandard functions that we run into again and again. :(

> 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;
> }

This behavior seems preferable in itself, but it's inconsistent with
what glibc and probably the BSDs do, so it's probably not a good idea.
glibc's behavior seems to match your previous version. This is leading
me to think maybe the code in forkpty should just stay separate. Do
you have other ideas?

Rich


  reply	other threads:[~2014-11-02  0:09 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-25 18:57 Felix Janda
2014-08-25 22:43 ` Rich Felker
2014-08-26 16:56   ` Felix Janda
2014-08-29 18:44     ` Felix Janda
2014-09-04 21:22     ` Szabolcs Nagy
2014-09-04 21:33       ` Rich Felker
2014-09-04 22:31         ` Justin Cormack
2014-09-05 17:23       ` Felix Janda
2014-09-05 17:29         ` Rich Felker
2014-09-05 18:52           ` Felix Janda
2014-10-31 16:19     ` Rich Felker
2014-11-01 21:15       ` Felix Janda
2014-11-01 21:45         ` Rich Felker
2014-11-01 22:07           ` Szabolcs Nagy
2014-11-01 22:27           ` Felix Janda
2014-11-01 22:43             ` Rich Felker
2014-11-01 22:56               ` Felix Janda
2014-11-02  0:09                 ` Rich Felker [this message]
2014-11-02 14:19                   ` Felix Janda
2014-11-02 16:28                     ` Rich Felker
2014-11-02 18:56                       ` Felix Janda
2014-11-02 22:28                         ` Rich Felker
2014-11-03 18:29                           ` Felix Janda
2014-12-21  0:58                             ` Rich Felker
2014-12-21  1:15                               ` Rich Felker
2014-12-21  1:38                               ` Rich Felker
2014-12-21  2:59                                 ` Rich Felker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20141102000944.GN22465@brightrain.aerifal.cx \
    --to=dalias@libc.org \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).