From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from m0.truegem.net (m0.truegem.net [69.55.228.47]) by sourceware.org (Postfix) with ESMTPS id 4A6913A4DC0B for ; Thu, 6 May 2021 09:25:01 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 4A6913A4DC0B Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=maxrnd.com Authentication-Results: sourceware.org; spf=none smtp.mailfrom=mark@maxrnd.com Received: (from daemon@localhost) by m0.truegem.net (8.12.11/8.12.11) id 1469P0jl097425 for ; Thu, 6 May 2021 02:25:00 -0700 (PDT) (envelope-from mark@maxrnd.com) Received: from 162-235-43-67.lightspeed.irvnca.sbcglobal.net(162.235.43.67), claiming to be "[192.168.1.20]" via SMTP by m0.truegem.net, id smtpdznWc2u; Thu May 6 02:24:56 2021 Subject: Re: python > 3.5: Issue with unix domain sockets To: cygwin-developers@cygwin.com References: <1620046759893.5340@bmw.de> <2cde4128-6a3d-7431-6608-a2184d23964a@cornell.edu> <134fa003-836f-1184-79eb-e31dfd852a64@maxrnd.com> From: Mark Geisert Message-ID: <50e76a43-48a1-f655-674a-1b4865dc62cf@maxrnd.com> Date: Thu, 6 May 2021 02:24:56 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0 SeaMonkey/2.49.4 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3.9 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, NICE_REPLY_A, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: cygwin-developers@cygwin.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Cygwin core component developers mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2021 09:25:03 -0000 Corinna Vinschen wrote: > On May 4 22:04, Mark Geisert wrote: >> Corinna Vinschen wrote: >>> On May 4 02:45, Mark Geisert wrote: >>>> [blah blah...] >>> You're supposed to call the special setsockopt(SO_PEERCRED) on the >>> accepting socket. The no_getpeereid property is inherited by the >>> accepted socket. >> >> Ah, of course. Well, I couldn't figure out a way to do the setsockopt() >> call some times but not others, because Python can't reach into the Cygwin >> DLL. Nor should it. >> >> Since this Python patch is supposed to be a temporary workaround, I took the >> tack that it should just ignore an error return from >> setsockopt(SO_PEERCRED). In this fashion the handshake will be turned off >> when it can be, and when it can't (on the accepted socket) the attempt will >> error but that error will be ignored. > > Sorry Mark, but I don't understand how you concluded that ignoring the > error from setsockopt(SO_PEERCRED) is the solution I pointed out above. > > The right thing to do is to call setsockopt(SO_PEERCRED) (and check its > return value) before calling listen() on the accepting socket. The > no_getpeereid property gets propagated to the accepted sockets and thus > there's no need to call it again for these sockets. The strategy requires more precise language than I used, sorry. I do understand what you're saying most recently, and have since my "of course" statement. Inside the Python runtime environment, I only get visibility to the socket Cygwin has provided at one point, which is where Python inits its own context for that socket. I can't tell whether the socket is the result of a socket() call or from an accept() call. I can't even tell whether it's connected. I can tell that it's AF_UNIX and can tell whether it's SOCK_DGRAM or SOCK_STREAM. So in this constrained situation, I decided to just call setsockopt(SO_PEERCRED) and ignore any errors. (Case 1:) If it doesn't error, the socket came from socket() and now has the peer handshake turned off. (Case 2:) If it does error, the socket came from accept(), i.e. it's an accepted socket, and though we couldn't turn off handshake here, it's already turned off due to inheritance from the accepting socket. The accepting socket has it turned off already because it was earlier Case 1 (i.e. both ends of the connection get treated, as long as they are both Python apps). I know that in general it's poor practice to ignore errors but given the constraints here and that the possible cases are (I believe) well known, this is a solution that works to solve the most recent issue and the original issue. Now that I think about it, the patch could be tightened up by only ignoring EALREADY rather than ignoring all errors. Would you be okay with that? Thank you for reviewing, ..mark