From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8249 invoked by alias); 22 Aug 2014 20:16:26 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 8239 invoked by uid 89); 22 Aug 2014 20:16:26 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-5.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.2 X-HELO: calimero.vinschen.de Received: from aquarius.hirmke.de (HELO calimero.vinschen.de) (217.91.18.234) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 22 Aug 2014 20:16:25 +0000 Received: by calimero.vinschen.de (Postfix, from userid 500) id B073E8E0789; Fri, 22 Aug 2014 22:16:22 +0200 (CEST) Date: Fri, 22 Aug 2014 20:16:00 -0000 From: Corinna Vinschen To: cygwin@cygwin.com Subject: Re: connect() hangs on a listen()ing AF_UNIX socket Message-ID: <20140822201622.GM32314@calimero.vinschen.de> Reply-To: cygwin@cygwin.com Mail-Followup-To: cygwin@cygwin.com References: <53F61B70.2020600@t-online.de> <20140821164402.GB21065@calimero.vinschen.de> <53F6450C.3070007@t-online.de> <20140822093923.GA12878@calimero.vinschen.de> <53F78CB1.9080406@t-online.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="DfnuYBTqzt7sVGu3" Content-Disposition: inline In-Reply-To: <53F78CB1.9080406@t-online.de> User-Agent: Mutt/1.5.23 (2014-03-12) X-SW-Source: 2014-08/txt/msg00451.txt.bz2 --DfnuYBTqzt7sVGu3 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 3352 On Aug 22 20:32, Christian Franke wrote: > Corinna Vinschen wrote: > >On Aug 21 21:14, Christian Franke wrote: > >>Easier and may work for Postfix: Add a Cygwin specific socket option li= ke > >>SO_DONT_NEED_PEERCRED which is set immediately after Postfix calls > >>socket(AF_UNIX, SOCK_STREAM). If set, no handshake occurs on > >>connect()/accept(). getpeerid()/SO_PEERCRED should fail then. > >Well, it's not *only* SO_PEERCRED. Another, the older part of the > >handshake, is about recognizing the peer. Since AF_UNIX sockets don't > >exist on Windows, Cygwin is using AF_INET sockets under the hood, and > >so *any* Windows process could accidentally connect to a Cygwin AF_UNIX > >socket. The handshake also aims to avoid this scenario. Only if the > >handshake worked, the peers can be sure to talk to another Cygwin > >process assuming an AF_UNIX socket. > > > >A Cygwin-specific socket option which switches off the handshake would > >disallow this peer recognition. How bad is that? I'm not sure. >=20 > Good question. >=20 > >Another potential solution might be to defer the AF_UNIX handshake to > >the first send/recv: > > > >Whatever the peers do, there is a certain protocol used. That means, > >there's an implicit understanding who's going to do the first send and > >who's doing the first recv. So, after connect/accept, both sides of the > >sockets go into "connected_but_handshake_missing" mode. On the first > >send/recv, the handshake gets started and if it fails, send/recv > >return ECONNRESET. >=20 > Is an actual handshake really required? It would possibly be sufficient t= hat > each peer sends its secret+credential and then expects a correct > secret+credential from the other peer before sending anything. >=20 > After actual connect()/accept(): >=20 > send our secret+cred (should not block due to TCP queuing). So both peers send their credentials... > if (! nonblocking recv peer secret+cred) > set_state(connected_but_secret_missing) > else > set_state(connected) This will almost always result in connected_but_secret_missing. It's probably ok to drop the recv attempt here entirely. > Before actual send()/recv()/getpeerid(): >=20 > if (state =3D=3D connected_but_secret_missing) { > if (! recv peer secret+cred) > abort_connection(ECONNRESET) > else > set_state(connected) > } Sounds like a nice idea. We should try that. I'm just not sure how much time I have left to work on this before my vaca next month. Do you have fun to look into that? We have waited so long for postfix, I guess a couple more weeks won't really hurt. Otherwise the easy solution you suggested before would be rather quickly implemented... > AFAICS this should provide the behavior required for postfix: client > connect() succeeds before server accept(). > It adds the following unusual behavior: client send() and getpeereid() wa= it > for server accept(). Same with recv. Well, that might be unusual, but in most cases send recv and getpeereid will be called after a connect/accept. It's as much a trade-off as the connect/accept requirement today. As a resort we'd still have the "easy" solution removing the credential exchange entirely. Corinna --=20 Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat --DfnuYBTqzt7sVGu3 Content-Type: application/pgp-signature Content-length: 819 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJT96UWAAoJEPU2Bp2uRE+gILcP/0OeaiwkQti0ohu3kUpgsXj/ h7EnYNA3GEx5SomApAddR6QHWElKdk2tekcHTVCCiGOm64hO3Y7Dy0rOugWfJGgs ymwTlVODeOsJXJwRBM4RN8uY9LSOzChsDnD/nCkboeYPLEqEIaXKAUBYTYxa6f4L bPvonlvyl29ou4SvHGMyOlUCicgs1jT9zpF/e6A0Kl0YCsZ8A2vOk/+igq2BlRoP V6g+VI4Z4YDzcKW2Ijm85H3xbLnnQTGvrRv0qjGP56jOaPTx+0abKAdV1wAzxePB LpxaaJmiuRuqfEQCBmU7hBX5p6xQVJFMoLd2Nh/KwRNWnq9PYJqY8ZpG0cFv4N0j rNoF/yNSk6eVu3y5A5CEmbJ6vZxKI6SAddLosYN43LQHdnSRgyl1PkzWFZp46II/ c9S5VSdxySQAqGdvu0WmQ2jwpX7q5ejUjcpFL4rEMeB2fBMkuPaYjIGKbNXDu990 eLW0WUuW5NMV8vFXxKMIO7dbP36pAxNjJ9CGcEr+H6zaFr6Ke3oVrzlJaJC2Ak8T 2mCxJlhInJl5Ey6afud0q3HiuoAivsmkrf1z5AODakJqmg0YAopKCI9jpqGUYCZs 5EBKpUCD09ZpudpwI4yRr6Tph7JwG58gyBU1YCT4JE+RjmZqHbYj1TbIcXsYqpGR 100yYAJyZoPqszMXEgJG =d14y -----END PGP SIGNATURE----- --DfnuYBTqzt7sVGu3--