EPERM on bind() ?

EPERM on bind() ?

[E. Madison Bray]

Hello,

I have had some users of the Jupyter Notebook [1] on Cygwin report an
crash on startup where, when the Notebook server tries to bind() to
the port it will listen on (TCP 8888) the bind() fails and errno is
set to EPERM, which is not an expected errno from bind().

Looking at the Cygwin sources, in net.cc I see that in
set_winsock_errno, EPERM is returned by default if there is some WSA
error for which there is no POSIX equivalent mapped.  Fine--EPERM is
as good as any other fallback I suppose (?) in that it unambiguously
indicates some unknown WSA error.

I'm just wondering if anyone has any idea what might cause such an
error.  Some third-party firewall or BLODA?  I can't reproduce it
myself.  Trying to bind to a port already in use correctly returns
EADDRINUSE.


[1] https://jupyter.org/

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: EPERM on bind() ?

[E. Madison Bray]

On Tue, Apr 23, 2019 at 2:17 PM E. Madison Bray wrote:
>
> Hello,
>
> I have had some users of the Jupyter Notebook [1] on Cygwin report an
> crash on startup where, when the Notebook server tries to bind() to
> the port it will listen on (TCP 8888) the bind() fails and errno is
> set to EPERM, which is not an expected errno from bind().
>
> Looking at the Cygwin sources, in net.cc I see that in
> set_winsock_errno, EPERM is returned by default if there is some WSA
> error for which there is no POSIX equivalent mapped.  Fine--EPERM is
> as good as any other fallback I suppose (?) in that it unambiguously
> indicates some unknown WSA error.
>
> I'm just wondering if anyone has any idea what might cause such an
> error.  Some third-party firewall or BLODA?  I can't reproduce it
> myself.  Trying to bind to a port already in use correctly returns
> EADDRINUSE.
>
>
> [1] https://jupyter.org/

Answering my own question after comparing the list on
https://docs.microsoft.com/en-us/windows/desktop/winsock/windows-sockets-error-codes-2
to Cygwin's wsock_errmap table this is a likely culprit:

> WSAEACCES
> 10013
> Permission denied.An attempt was made to access a socket in a way forbidden by its access permissions.
> An example is using a broadcast address for sendto without broadcast permission being set using
> setsockopt(SO_BROADCAST).
> Another possible reason for the WSAEACCES error is that when the bind function is called (on Windows NT
> 4.0 with SP4 and later), another application, service, or kernel mode driver is bound to the same address
> with exclusive access. Such exclusive access is a new feature of Windows NT 4.0 with SP4 and later, and is
> implemented by using the SO_EXCLUSIVEADDRUSE option.

This appears to be missing from the wsock_errmap table, but should
obviously map to EACCES.  I'll supply a patch.

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: EPERM on bind() ?

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1683 bytes --]

On Apr 23 14:17, E. Madison Bray wrote:
> Hello,
> 
> I have had some users of the Jupyter Notebook [1] on Cygwin report an
> crash on startup where, when the Notebook server tries to bind() to
> the port it will listen on (TCP 8888) the bind() fails and errno is
> set to EPERM, which is not an expected errno from bind().
> 
> Looking at the Cygwin sources, in net.cc I see that in
> set_winsock_errno, EPERM is returned by default if there is some WSA
> error for which there is no POSIX equivalent mapped.  Fine--EPERM is
> as good as any other fallback I suppose (?) in that it unambiguously
> indicates some unknown WSA error.

This code is as old as it can get.  The Winsock error fallback to EPERM
predates the Cygwin import into the public CVS repo on sourceware.org in
2000, and the pre-2000 ChangeLogs don't mention it.  There's a good
chance the mapping defaults to EPERM since 1996 when the first socket
support was added.

It's probably a good idea to change the default to EACCES, as for other,
non-WinSock errors.

> I'm just wondering if anyone has any idea what might cause such an
> error.

Nobody knows.  The problem is that we only know the POSIX fallback
but not the actual WSOCK error code.

If you can manage to run the server under strace to reproduce the issue,
then there will be an error message in strace along the lines of

"fhandler_socket*.cc:42 - winsock error 12345 -> errno 1"

The point here is to know what winsock error code that actually is.
What we can do then is to map it to a better POSIX error code or
maybe even see if there's a bug in Cygwin.


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: EPERM on bind() ?

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 2259 bytes --]

On Apr 23 14:28, E. Madison Bray wrote:
> On Tue, Apr 23, 2019 at 2:17 PM E. Madison Bray wrote:
> >
> > Hello,
> >
> > I have had some users of the Jupyter Notebook [1] on Cygwin report an
> > crash on startup where, when the Notebook server tries to bind() to
> > the port it will listen on (TCP 8888) the bind() fails and errno is
> > set to EPERM, which is not an expected errno from bind().
> >
> > Looking at the Cygwin sources, in net.cc I see that in
> > set_winsock_errno, EPERM is returned by default if there is some WSA
> > error for which there is no POSIX equivalent mapped.  Fine--EPERM is
> > as good as any other fallback I suppose (?) in that it unambiguously
> > indicates some unknown WSA error.
> >
> > I'm just wondering if anyone has any idea what might cause such an
> > error.  Some third-party firewall or BLODA?  I can't reproduce it
> > myself.  Trying to bind to a port already in use correctly returns
> > EADDRINUSE.
> >
> >
> > [1] https://jupyter.org/
> 
> Answering my own question after comparing the list on
> https://docs.microsoft.com/en-us/windows/desktop/winsock/windows-sockets-error-codes-2
> to Cygwin's wsock_errmap table this is a likely culprit:
> 
> > WSAEACCES
> > 10013
> > Permission denied.An attempt was made to access a socket in a way forbidden by its access permissions.
> > An example is using a broadcast address for sendto without broadcast permission being set using
> > setsockopt(SO_BROADCAST).
> > Another possible reason for the WSAEACCES error is that when the bind function is called (on Windows NT
> > 4.0 with SP4 and later), another application, service, or kernel mode driver is bound to the same address
> > with exclusive access. Such exclusive access is a new feature of Windows NT 4.0 with SP4 and later, and is
> > implemented by using the SO_EXCLUSIVEADDRUSE option.
> 
> This appears to be missing from the wsock_errmap table, but should
> obviously map to EACCES.  I'll supply a patch.

Good catch!  As I *just* wrote in my other reply, we should better
default to EACCES.  It should be sufficient to change the default then.
I'm looking forward to your patch submission.


Thanks,
Corinna

-- 
Corinna Vinschen
Cygwin Maintainer

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: EPERM on bind() ?

[E. Madison Bray]

On Tue, Apr 23, 2019 at 2:48 PM Corinna Vinschen wrote:
>
> On Apr 23 14:28, E. Madison Bray wrote:
> > On Tue, Apr 23, 2019 at 2:17 PM E. Madison Bray wrote:
> > >
> > > Hello,
> > >
> > > I have had some users of the Jupyter Notebook [1] on Cygwin report an
> > > crash on startup where, when the Notebook server tries to bind() to
> > > the port it will listen on (TCP 8888) the bind() fails and errno is
> > > set to EPERM, which is not an expected errno from bind().
> > >
> > > Looking at the Cygwin sources, in net.cc I see that in
> > > set_winsock_errno, EPERM is returned by default if there is some WSA
> > > error for which there is no POSIX equivalent mapped.  Fine--EPERM is
> > > as good as any other fallback I suppose (?) in that it unambiguously
> > > indicates some unknown WSA error.
> > >
> > > I'm just wondering if anyone has any idea what might cause such an
> > > error.  Some third-party firewall or BLODA?  I can't reproduce it
> > > myself.  Trying to bind to a port already in use correctly returns
> > > EADDRINUSE.
> > >
> > >
> > > [1] https://jupyter.org/
> >
> > Answering my own question after comparing the list on
> > https://docs.microsoft.com/en-us/windows/desktop/winsock/windows-sockets-error-codes-2
> > to Cygwin's wsock_errmap table this is a likely culprit:
> >
> > > WSAEACCES
> > > 10013
> > > Permission denied.An attempt was made to access a socket in a way forbidden by its access permissions.
> > > An example is using a broadcast address for sendto without broadcast permission being set using
> > > setsockopt(SO_BROADCAST).
> > > Another possible reason for the WSAEACCES error is that when the bind function is called (on Windows NT
> > > 4.0 with SP4 and later), another application, service, or kernel mode driver is bound to the same address
> > > with exclusive access. Such exclusive access is a new feature of Windows NT 4.0 with SP4 and later, and is
> > > implemented by using the SO_EXCLUSIVEADDRUSE option.
> >
> > This appears to be missing from the wsock_errmap table, but should
> > obviously map to EACCES.  I'll supply a patch.
>
> Good catch!  As I *just* wrote in my other reply, we should better
> default to EACCES.  It should be sufficient to change the default then.
> I'm looking forward to your patch submission.

Thanks Corinna for the historical background (I didn't even realize
how old that code was) and for the confirmation.  I'll do that.

On one hand EPERM sort of make sense just because it didn't map to
anything else, so it was useful in this case in identifying the
problem.  At the same time it's not a valid error for most any
socket-related function defined by POSIX that I can find, so EACCES
makes more sense.

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple