X-Recipient: archive-cygwin AT delorie DOT com
X-Spam-Check-By: sourceware.org
Date: Fri, 2 Apr 2010 15:53:17 +0200
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: tty initialization failure under cygwin 1.7.2?
Message-ID: <20100402135317.GD9551@calimero.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <443209 DOT 59478 DOT qm AT web55105 DOT mail DOT re4 DOT yahoo DOT com>  <20100402113641 DOT GA9776 AT calimero DOT vinschen DOT de>  <4BB5F03D DOT 9090209 AT shaddybaddah DOT name>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4BB5F03D.9090209@shaddybaddah.name>
User-Agent: Mutt/1.5.20 (2009-06-14)
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
List-Id: <cygwin.cygwin.com>
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

On Apr  2 13:25, Shaddy Baddah wrote:
> Hi,
> 
> On 2/04/2010 11:36 AM, Corinna Vinschen wrote:
> >On Apr  1 14:31, Eric Berge wrote:
> >>
> >>I recently updated to 1.7.2 from 1.7.1 with the March 15 development
> >>patch and noticed I was getting some process failures.  In particular
> >>I was running the Coverity static analysis tool, and was getting an
> >>error about not being able to "initialize fd 0 for /dev/tty0".
> >>
> >>This problem does not appear to occur with remote desktop, just with
> >>ssh.
> >>
> >>I've been searching around for a simpler version of the problem
> >>and this is what I found:
> >>
> >>The test scenario is to do the following:
> >>
> >>1. ssh into an cygwin sshd server with an explicit password
> >>2. Run "cmd"
> >>3. From "cmd" run "ls"
> >>
> >>I unfortunately no longer have the 1.7.1 + Mar15 patch running but
> >>with cygwin 1.5 and running "ls" lists the entries of the directory
> >>as expected.  However, running on 1.7.2 has the following output:
> >>
> >>C:\cygwin\home\eberge>ls
> >>ls
> >>      12 [main] ls 3984 C:\cygwin\bin\ls.exe: *** fatal error - couldn't initialize fd 0 for /dev/tty0
> >>
> >>C:\cygwin\home\eberge>
> >>
> >>I hope this is reflective of the problem I had with Coverity.  It is
> >>the same error message at least.  Is this indicative of an underlying
> >>problem in 1.7.2 or is this related to any sort of reconfiguration I
> >>need to do on my box after updating to 1.7.2?
> >I'm wondering if that's a side effect with some other software.  I can
> >not reproduce your problem.  I tried your test scenario and it works for
> >me.  I don't get any weird error from ls.
> 
> I suspect this is related to the same issue, related to user
> privilege, that I described in
> http://cygwin.com/ml/cygwin-developers/2010-02/msg00005.html. As I
> understood it from that bit of debug (which I have not returned to
> btw), it boils down to an OS limitation preventing Cygwin from
> emulating the correct permissions of a tty device. ie. the tty device
> appears to be owned by the user, but the tty master is in fact
> owned/permed as the SYSTEM(like) user of the sshd session
> process. Only Administrators can get at it (with the underlying
> OpenProcess() call).
> 
> I would have expected this to occur with 1.7.1 as well though.
> 
> Is that accurate?

Oh, right.  I just tested with a normal user, rather than an admin user
and I can reproduce the problem now.  Cygwin still has to have acess to
the process which opened the master pty, and that process is running in
the cyg_server context.  Non-admin processes don't have the right to
open that process, so they fail at process initialization.  This is no
problem as long as you're not breaking the Cygwin process chain.  As
soon as a non-Cygwin process is in the way, you lost the inherited
connection to the tty and another Cygwin process has yet again to find
out that its stdio desscriptors are connected to a Cygwin pseudo tty.

I just found that this problem only didn't show up in Cygwin 1.5,
because Cygwin 1.5 did not perform error checking in a specific piece
of code (function dtable::init_std_file_from_handle).

This needs fixing but I don't have a quick solution, other than not
doing the ssh -> cmd -> some-other-cygwin-processtwist for now.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple