Re: python > 3.5: Issue with unix domain sockets

[Mark Geisert <mark@maxrnd.com>]

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.

Assuming the connect_state check is needed (seems good for sanity check if nothing 
else) then I think I need to adjust when the Python patch is invoked.  Possibly 
distinguishing between Python-level accept()'s listening socket and returned 
socket.  I think that's right, assuming the Cygwin parts are operating correctly.

Does this sound like the right way to go?
Thanks for any comments either way.

..mark