From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.134]) by sourceware.org (Postfix) with ESMTPS id ECD4D3A9DC39 for ; Thu, 6 May 2021 10:30:28 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org ECD4D3A9DC39 Authentication-Results: sourceware.org; dmarc=fail (p=none dis=none) header.from=cygwin.com Authentication-Results: sourceware.org; spf=fail smtp.mailfrom=corinna-cygwin@cygwin.com Received: from calimero.vinschen.de ([24.134.7.25]) by mrelayeu.kundenserver.de (mreue009 [212.227.15.167]) with ESMTPSA (Nemesis) id 1MvJs9-1lMWG32ovx-00rHeY for ; Thu, 06 May 2021 12:30:26 +0200 Received: by calimero.vinschen.de (Postfix, from userid 500) id 03F02A80DBD; Thu, 6 May 2021 12:30:26 +0200 (CEST) Date: Thu, 6 May 2021 12:30:25 +0200 From: Corinna Vinschen To: cygwin-developers@cygwin.com Subject: Re: python > 3.5: Issue with unix domain sockets Message-ID: Reply-To: cygwin-developers@cygwin.com Mail-Followup-To: cygwin-developers@cygwin.com References: <1620046759893.5340@bmw.de> <2cde4128-6a3d-7431-6608-a2184d23964a@cornell.edu> <134fa003-836f-1184-79eb-e31dfd852a64@maxrnd.com> <50e76a43-48a1-f655-674a-1b4865dc62cf@maxrnd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <50e76a43-48a1-f655-674a-1b4865dc62cf@maxrnd.com> X-Provags-ID: V03:K1:TmMsE5q9gRzAT7LQSmbpbJWZNolN3f8n9cwJZQk/VfHUeXtGmNE k4QGuiautA5NfpktTDkhrY/krrFTJsQ5XiPQLvuvwkpDDS5hRCDCHz2capD5lBQIL09ycPN Ya26CKhS2ybi1K8EGJKSVW2VjB62ZbJ26QVO7gaoLAPNez+PHitHV1F5JIUUBKyaOcnELRv BzBKr0cU1++crNtoGOROw== X-UI-Out-Filterresults: notjunk:1;V03:K0:iwG4wbcn1ow=:L2inDEy65ZseDZxNbInIBC 5oM/03LEbfJesrIvKyHgNwf8IbgyiJsbXcbsfnf4nuAg1/1UbQsOvJFiL3/xgeAYScSI49/Xf MzRy9FlG20Yxb5Uww4IKpNx8MoaxFJ2wag4lX5RVAM5Sow0E90Uh0PBK+kQ4oDBBUH94roQpD w1gO1a1BpluFJ98J/NNfaPmnTxWSGSJG/1kbtPKx+08BVNHNbcUOErlQegd2K/Wf1MHDhwwTD wcp1kg7LFXvBiDfCSoO1Fkc8XW9Z86aaZxxMd00QyG+Fof1H671rkmwgL7EGA5Fe2XBBiq7fJ KdCKrHQ8Wql3ztHm6v1CFPanG8L28N0OAIbhS4Xh49NHAjt/oGnaS9sG1Rcn5sPrWrt3Ut+Ny ZgthcK9jonFtZ/CM/9glQbKd0bedfMZR9FTyMDYBchBJgW6Hv2iooMlRhWbyNbd+yb236m8Uh dbMIjeNtNsxTsKv0gvQa2+5TqOnX8RsUxP17d1QHjEwmX8dszpjf6N6lR5ep04Q1rUXEnNQ8+ GEv7PKUMujppr1R9kIQANM= X-Spam-Status: No, score=-100.3 required=5.0 tests=BAYES_00, GOOD_FROM_CORINNA_CYGWIN, KAM_DMARC_NONE, KAM_DMARC_STATUS, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_NEUTRAL, TXREP autolearn=ham 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 10:30:30 -0000 On May 6 02:24, Mark Geisert wrote: > 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. Ah, ok. Sounds like a shitty interface to me, but if that's what you have to work with... > 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? Sounds good to me. Thanks for explaining the situation! Corinna