This is the mail archive of the cygwin-developers@cygwin.com 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: [corinna-cygwin@cygwin.com: Re: ENOTSOCK errors with cygwin dll 1.3.21 and 1.3.22]


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

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


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