This is the mail archive of the
mailing list for the Cygwin project.
Re: tty initialization failure under cygwin 1.7.2?
>On Apr 2 13:25, Shaddy Baddah wrote:
>> 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
>> 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.
Yes, my analysis on this being reproducible in 1.7.1+March-15-snapshot
was probably wrong. It was based on a questionable recollection.
Sorry about that but I'm glad that did not appear to impede the9
quick understanding of the problem.
So we can work around this be being sure our Coverity runs have
Administrator privileges for now (or is there a more limited privilege
we can assign via local policy -- don't dig for this I'm just curious
if there's already a known answer).
I realize the fix may not be quick in coming but if you're interested
in my giving a development snapshot a try, let me know.
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple