[firstname.lastname@example.org: Re: ENOTSOCK errors with cygwin dll 1.3.21 and 1.3.22]
Pierre A. Humblet
Wed May 28 13:24:00 GMT 2003
Corinna Vinschen wrote:
> On Tue, May 27, 2003 at 07:44:39PM -0400, Pierre A. Humblet wrote:
> > 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.
> I tried it and it doesn't change the behaviour. WSADuplicateSocket()
> still returns WSAEINVAL. Too bad, the idea was stunning.
> However, what if it's just the wrong parameter? Come to think of it,
> the 2nd parameter is the own process id. What if the access to the own
> process is limited from the unpriv'ed users perspective?
> The next try would be to change the access to the process handle, right?
Another test, more direct, would be to point prot_info_ptr to a dynamic
(on the stack) WSAPROTOCOL_INFOA structure during the dup operation,
and to restore it to point to the cygheap area at the end of the dup.
If it works, we know the problem is somehow related to the cygheap
and we can start looking it it.
The cygheap permission explanation is not convincing because the cygheap
is modified at the end of seteuid32() and there are no problems there.
Perhaps WSADuplicateSocketA does something special.
More information about the Cygwin-developers