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

["Pierre A. Humblet" <Pierre dot Humblet at ieee dot org>]

At 12:41 PM 5/26/2003 +0200, Corinna Vinschen wrote:
>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?

Here is a wild one, trying to connect dots:

1) WSADuplicateSocket works when the process is started from Windows, 
   fails when starting from Cygwin. 
2) WSADuplicateSocket works after setuid as long as Administrators
   is in the token groups.
3) WSADuplicateSocket writes the protocol info to calloc'ed memory,
   on the cygheap.
4) When starting from Windows, the cygheap is plain memory. When 
   started from Cygwin it is file mapped.
5) The file mapping is created with sec_none, which causes a default
   security descriptor to be used. Those usually give rights to
   Administrators, but not to the setuid'ed user.

There are some holes in this explanation... I don't have access
to machines exhibiting the problem. A quick check (Jason ?) would be 
to change "sec_none" to "sec_all" on line 85 of cygheap.cc and see if
that affects the behavior.

Pierre