Request for help debugging screen problem

Corinna Vinschen corinna-cygwin@cygwin.com
Fri Feb 5 15:28:00 GMT 2010


On Feb  5 10:00, Christopher Faylor wrote:
> On Fri, Feb 05, 2010 at 03:51:54PM +0100, Corinna Vinschen wrote:
> >On Feb  5 09:35, Christopher Faylor wrote:
> >> On Fri, Feb 05, 2010 at 02:46:48PM +0100, Corinna Vinschen wrote:
> >> >On Feb  5 10:42, Shaddy Baddah wrote:
> >> >> before and after the ReadFile the error code can return a different
> >> >> value. ie. a call to the following function, returns different
> >> >> values:
> >> >> 
> >> >> ssize_t client_request::error_code() const;
> >> >> 
> >> >> I'm curious as to how this could be. Is there some callback function
> >> >> registered via the Windows API that ReadFile calls at various points
> >> >> in its execution? Or is another thread setting this value?
> >> >> 
> >> >> Any help would be greatly appreciated.
> >> >
> >> >Can yopu expolain this in more detail, please?  What error codes
> >> >are returned, and how do you trigger the effect?
> >> 
> >> Also, unless you have CYGWIN=server set, this code should not be used
> >> by the pty handler so I don't know why you're looking here.
> >
> >Beep.  CYGWIN=server doesn't exist anymore.  But, of course, it still
> >requires a running cygserver.
> 
> Ah, right.  So, I have never debugged the tty handling in cygserver.  Is

Same here.

> this the root cause of some of the screen error reports?

I can't tell about the screen problem, but I'm wondering for a while if
the tty handle stuff in Cygserver is really required, or if we should
drop this code.

How exactly was the default mechanism supposed to be a security hole?
IIRC the idea was that the inferior process has PROCESS_DUP_HANDLE
permission on the tty master process.  That's by definition not a
security problem if the inferior process is running in the same user
context as the tty master process anyway.  So we just have to look at
the case of the inferior running in another user context:

- If the inferior process user is an admin user, there's also no
  security problem, because the admin user has by design other ways to
  exploit the tty master process.

- If the inferior process is running under a non-privileged account,
  then the security settings of the tty master process handles are
  marking the border.  If the security settings are correct, nothing bad
  should happen.  If the security settings are bad, it's a bug in Cygwin
  and should be fixed there.

Am I missing something?  If not, I don't see a reason to keep the
cygserver way of creating inferior process pty handles.

If we really want to make this more secure, there's very likely another
simple method to get the pipe handles without having to open the tty
master process with PROCESS_DUP_HANDLE access.  For instance, what if we
create pty pipes with the ability to take unlimited connections
(PIPE_UNLIMITED_INSTANCES), and then open the pty pipes by name?


Corinna

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



More information about the Cygwin-developers mailing list