This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: tty initialization failure under cygwin 1.7.2?


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

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:

      12 [main] ls 3984 C:\cygwin\bin\ls.exe: *** fatal error - couldn't initialize fd 0 for /dev/tty0


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 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?


-- Problem reports: FAQ: Documentation: Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]