From owner-freebsd-arch Thu Jul 27 16:27:33 2000 Delivered-To: freebsd-arch@freebsd.org Received: from merc94.us.sas.com (merc94.us.sas.com [149.173.6.4]) by hub.freebsd.org (Postfix) with ESMTP id 2C5BF37BC5F for ; Thu, 27 Jul 2000 16:27:28 -0700 (PDT) (envelope-from brdean@unx.sas.com) Received: from merc94.us.sas.com ([127.0.0.1]) by merc94.us.sas.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2651.58) id PDG9FVC0; Thu, 27 Jul 2000 19:27:26 -0400 Received: from 10.28.149.26 by merc94.us.sas.com (InterScan E-Mail VirusWall NT); Thu, 27 Jul 2000 19:27:26 -0400 (Eastern Daylight Time) Received: from tribble.unx.sas.com by mozart (5.65c/SAS/Domains/5-6-90) id AA03248; Thu, 27 Jul 2000 19:27:26 -0400 Received: from localhost (brdean@localhost) by tribble.unx.sas.com (8.9.3/8.9.1) with ESMTP id TAA78169; Thu, 27 Jul 2000 19:27:26 -0400 (EDT) (envelope-from brdean@unx.sas.com) X-Authentication-Warning: tribble.unx.sas.com: brdean owned process doing -bs Date: Thu, 27 Jul 2000 19:27:26 -0400 (EDT) From: Brian Dean To: Luoqi Chen Cc: bde@zeta.org.au, freebsd-arch@FreeBSD.ORG Subject: Re: isatty() reports false results In-Reply-To: <200007272036.e6RKaBR18831@lor.watermarkgroup.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 27 Jul 2000, Luoqi Chen wrote: > > I suppose, at worst, we could move the TIOCGETA handling to precede > > the check for the slave being open. Would that be valid? > > > The master is not in the normal sense a tty, I think we could just change > the return code from EAGAIN to ENOTTY to conform to the POSIX standard. > As for isatty(), I don't think we need to change anything, it is a pilot > error to call isatty() on the master side of the pty. The way this section of code gained my attention was when I was setting up a VPN using ppp over ssh. For example, my setup gets instantiated using something like this: % /usr/local/bin/pty-redir \ /usr/bin/ssh -t -e none -o 'Batchmode yes' \ -i $key -l $user $host > ~/vpndev % /usr/sbin/pppd `cat ~/vpndev` $localip:$remoteip In the above, pty-redir allocates a pty, opens the master side of it, prints out the name of the slave side, dup2()'s the master side as stdin and stdout, forks off ssh, then exits. This leaves ssh using the master side as stdin/stdout. On the remote host, the login shell for $user is just /usr/sbin/pppd. The local invocation of pppd uses the slave side of the pty which talks to the remote side and establishes the connection. [This, btw, shows some of the true elegance of Unix - the ability to chain together several seemingly unrelated processes in order instantiate a construct that the original authors of the individual pieces did not necesarily intend or conceive.] Where the pty ioctl() code gets involved is with the '-t' option to ssh. This options causes ssh to request that the remote sshd allocate a pty for the remote pppd which it seems to need. Ssh wants to validate that stdin is really a tty before making the request to the remote side. To do this it calls 'isatty()', which ends up being called on the master side of a pty pair in this case. Perhaps ssh is trying to be smarter than it should be? So based on your statement above, about pilot error, should the validation check be removed from 'ssh'? I have no problem with that, assuming we can maintain this diff or get the contributors to make the same change. Then again, this also seems like a simple matter of timing. If I modify pty-redir slightly to add a delay after the parent exits, but before the child execs ssh, that will give the local pppd a chance to open the slave side before ssh tries to call isatty(). Kind've kludgy, but it works (most of the time - under high system load it may not work). The only problem is that, if we don't change either 'isatty()', or 'ssh', or the pty driver, then others are going to run into this same problem if, like me, they come across the Linux VPN HOW-TO and use it for ideas in setting up a VPN on FreeBSD :(. Our pty driver seems to behave differently in this respect to Linux and NetBSD (and probably others as well). -Brian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message