This is the mail archive of the cygwin-developers 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: Request for help debugging screen problem


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


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