Request for help debugging screen problem

[Shaddy Baddah]

Hi,

On 8/02/2010 9:51 AM, Corinna Vinschen wrote:
> On Feb  7 16:09, Shaddy Baddah wrote:
>> Hi,
>>
>> On 7/02/2010 3:48 PM, Shaddy Baddah wrote:
>>> However, I now have a new problem. Say I have no screen sessions running
>>> at all:
>>>
>>> shaddy@*** ~
>>> $ screen -r
>>> There is no screen to be resumed.
>>>
>>> But I try an strace:
>>>
>>> shaddy@*** ~
>>> $ strace -o /tmp/screen-r+cygserver-down.strace screen -r
>>> 23025 [main] screen 5340 C:\software\cygwin\bin\screen.exe: *** fatal
>>> error - couldn't initialize fd 0 for /dev/tty2
>>>
>>> I've completely lost faith in my strace scenarios now. This last
>>> scenario is how I came to determine that screen was trying to call
>>> OpenProcess() on the cyg_server owned sshd process. I was intending to
>>> mention it as it as it was unusual.
>>>
>>> Why doesn't this last strace just output the same "There is no screen to
>>> be resumed." message? I am now hesistant to go on using strace, as I'm
>>> not sure it is helping me analyse my initial problem. It seems to be
>>> creating problems of its own???
>>
>> I just thought of this where inspiration usually takes hold.
>>
>> shaddy@*** ~
>> $ strace -o /tmp/ls.strace ls
>>    22886 [main] ls 4808 C:\software\cygwin\bin\ls.exe: *** fatal
>> error - couldn't initialize fd 0 for /dev/tty2
>>
>> The OpenProcess() thing, it's actually strace having trouble
>> attaching to the ssh tty, right?
>
> strace is a non-Cygwin application.  When you call the application like
> this, the inferior process has to initialize the pseudo tty by calling
> OpenProcess and in *that* scenario the master process is actually sshd.

That's understood.

> It's the same OpenProcess problem in just another shape.

Just to clarify. If you mean the same problem as reattaching to screen, 
I think the new developments reveal that I have no data at all on that. 
It could well be OpenProcess) as well, but I can't determine because 
screen -r isn't even being run by strace. strace is failing before it 
executes the process (evidenced by no ls output when I do a strace ls).

With regards to the calling OpenProcess() on the master, I'd like to 
outline a disparity here. In my cygwin scenario, the session sshd 
process is not owned by the user, but by the same as its parent, cyg_server.

In linux, the session ssh is setuid'ed to the authenticated user. I'm 
wondering why this is not the case with cygwin. I got the impression 
from 
http://www.cygwin.com/cygwin-ug-net/ntsec.html#ntsec-setuid-overview 
that it was describing the sshd case in particular.

I'd like to assert that barring any Windows issue that would exclude it, 
cygwin should be like linux.

And this not because it would solve the strace issue, but just because 
it seems proper. In fact, I don't think having the session sshd owned by 
the authenticated user will solve the strace issue. I just tried 
manipulating in Process Explorer both the permissions, and then failing 
them, the ownership of the session ssh process in an attempt to get 
OpenProcess()/strace to succeed. This has failed.

My next step is to build screen and try to debug it to a point where I 
can find where in the cygwin dll (if in fact it is the cygwin at fault) 
that there is an issue. Beyond that, without strace at my disposal, I'm 
a bit stuck on how I'm going to debug cygwin. Help would be appreciated.

Thanks in advance,
Shaddy