Re: python > 3.5: Issue with unix domain sockets

[Corinna Vinschen <corinna-cygwin@cygwin.com>]

On May  4 02:45, Mark Geisert wrote:
> Mark Geisert wrote:
> > Ken Brown via Cygwin wrote:
> > > On 5/3/2021 8:57 AM, Maximilian.Blenk--- via Cygwin wrote:
> > > > Incorrect Behavior:
> > > > Server:
> > > > $ python3.7 server.py
> > > > starting up on ./uds_socket
> > > > waiting for a connection
> > > > Traceback (most recent call last):
> > > >    File "server.py", line 27, in <module>
> > > >      connection, client_address = sock.accept()
> > > >    File "/usr/lib/python3.7/socket.py", line 214, in accept
> > > >      sock = socket(self.family, self.type, self.proto, fileno=fd)
> > > >    File "/usr/lib/python3.7/socket.py", line 151, in __init__
> > > >      _socket.socket.__init__(self, family, type, proto, fileno)
> > > > SystemError: <slot wrapper '__init__' of '_socket.socket'
> > > > objects> returned NULL without setting an error
> > > > 
> > > > Client:
> > > > $ python3.7 client.py
> > > > connecting to ./uds_socket
> > > > sending b'This is the message.  It will be repeated.'
> > > > closing socket
> > > > Traceback (most recent call last):
> > > >    File "client.py", line 27, in <module>
> > > >      data = sock.recv(16)
> > > > ConnectionResetError: [Errno 104] Connection reset by peer
> > > 
> > > I wonder if this has the same cause as the problem reported here:
> > > 
> > >    https://cygwin.com/pipermail/cygwin/2021-February/247884.html
> > > 
> > > Mark, can you check that?
> 
> This issue is indeed related to the Python patch released to Python
> 3.{6,7,8} but not Python 3.5 or earlier.  I'm discussing here because the
> situation involves Python internals doing socket operations and Cygwin's
> AF_UNIX support is shaky in some aspects (that Ken's work will likely fix to
> the relief of everyone!).
> 
> The purpose of the Python patch is to disable the normal peer handshake that
> starts each AF_UNIX connection.  So whenever a Python app obtains an AF_UNIX
> socket, either from socket() or accept(), the internal routine that inits
> Python-level state was patched to call setsockopt() to turn off the
> handshake.
> 
> But it turns out that fhandler_socket_local::accept4() sets the socket's
> connect_state to "connected", on line fhandler_socket_local.cc:1086.  Then
> when the wrapping Python patch calls setsockopt() we end up in
> ::af_local_set_no_getpeereid(), which is good, but the socket is marked
> "connected" so the result is an EALREADY error that rather clumsily knocks
> out both the server and client apps.

You're supposed to call the special setsockopt(SO_PEERCRED) on the
accepting socket.  The no_getpeereid property is inherited by the
accepted socket.


Corinna