[corinna-cygwin@cygwin.com: Re: ENOTSOCK errors with cygwin dll 1.3.21 and 1.3.22]

Corinna Vinschen vinschen@redhat.com
Mon May 26 11:16:00 GMT 2003

On Sun, May 25, 2003 at 06:27:06PM -0400, Pierre A. Humblet wrote:
> At 05:20 PM 5/25/2003 -0400, Christopher Faylor wrote:
> >On Sun, May 25, 2003 at 05:03:02PM -0400, Pierre A. Humblet wrote:
> >>I would like to better understand what's going on, at least until
> >>we are close to a release. 

Some thoughts:

- Basically the different behaviour on the otherwise same system is
  probably due to different security settings and/or different patch
  levels (magic spell: "Windows Update") of the OS.  So let's just take
  it as given and beyond our control.

- The socket is created by the privileged account with some strict
  security settings, probably determined by the access token at the
  time of the socket creation.

- The access after the user context switch is restricted due to the
  new access token.  But sending/receiving on that socket seem to
  work fine, why does the duplication of the socket fail?

- If Winsock2 is available (which means always except for ancient
  stock 95) we don't duplicate the socket after creation in net.cc,
  set_socket_inheritance() to allow socket inheritance, since the
  sockets are not inherited as other handles.  They get duplicated
  by the WSASocket/WSADuplicateSocket mechanism.  We do even suppress
  inheritance in net.cc, fdsock() so that we don't get dangling
  handles in the child process.

- Well, what if the original access token of the socket does not allow
  PROCESS_DUP_HANDLE access to non-privileged accounts?  Or even *any*
  other account?  This would explain why the WSASocket/WSADuplicateSocket
  mechanism fails.  And it would also explain why a DuplicateHandle()
  under the non-priv'd account fails.  Perhaps we can workaround that
  by duplicating the socket with "all access" and closing the original
  socket on creation time.

- Another chance is that we have a fault in the *new* access token,
  the one we created for the non-priv'd account.  Actually I have
  no idea what that could be since it doesn't look wrong.

Am I missing something?  Anybody with another idea?

> Don't you think we should improve the sparse file behavior? I could
> submit a fix in a few days. 

I've already checked something in.


Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Developer                                mailto:cygwin@cygwin.com
Red Hat, Inc.

More information about the Cygwin-developers mailing list