From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32147 invoked by alias); 22 Aug 2014 09:39:27 -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 32136 invoked by uid 89); 22 Aug 2014 09:39:27 -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 09:39:26 +0000 Received: by calimero.vinschen.de (Postfix, from userid 500) id C2CF08E0789; Fri, 22 Aug 2014 11:39:23 +0200 (CEST) Date: Fri, 22 Aug 2014 09:39:00 -0000 From: Corinna Vinschen To: cygwin@cygwin.com Subject: Re: connect() hangs on a listen()ing AF_UNIX socket Message-ID: <20140822093923.GA12878@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> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="C7zPtVaVf+AK4Oqc" Content-Disposition: inline In-Reply-To: <53F6450C.3070007@t-online.de> User-Agent: Mutt/1.5.23 (2014-03-12) X-SW-Source: 2014-08/txt/msg00436.txt.bz2 --C7zPtVaVf+AK4Oqc Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 3301 On Aug 21 21:14, Christian Franke wrote: > Corinna Vinschen wrote: > >On Aug 21 18:16, Christian Franke wrote: > >>Corinna Vinschen wrote (in thread "[ITP] libsuexec 1.0"): > >>>Postfix for Cygwin would be *so* nice. Sigh. ... > >>Due to the following problem, Postfix hangs during startup (and blocks = any > >>possible "[ITP] postfix ..."): > >> > >>If a AF_UNIX socket is in listen()ing state, a client connect() should > >>succeed immediately. On Cygwin, connect() waits until the server site > >>accept()s the connection. > >> > >>Testcase: > >>... > >> > >> > >>This is likely because fhandler_socket::af_local_connect() waits for so= me > >>secret. Sending it in af_local_accept() is too late in this case. > >> > >>Unfortunately the event handling of postfix relies on the correct behav= ior > >>and there is possibly no easy workaround. > >Off the top of my head I don't see one inside the Cygwin DLL :( >=20 > Complex but may work: A fhandler_socket::listen() on a AF_UNIX/SOCK_STREAM > socket starts a thread which accept()s connections, performs the handshake > and puts the new socket descs in a queue. fhandler_socket::accept4() then= no > longer calls accept() but waits for the next entry in the queue. Yeah, that might be very tricky, especially if the executable forks and execs after calling listen. > >The problem is that the package exchange at the start of an > >accept/connect is required to be able to exchange credentials. This in > >turn is required for getpeereid and the SO_PEERCRED socket option which > >is utilized at least by sshd. >=20 > Easier and may work for Postfix: Add a Cygwin specific socket option like > 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. 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. This might be easier to implement and might even get rid of the special code in select handling the AF_UNIX handshake after a non-blocking connect. The potential problem here is that this might require another set of changes to cover select... Corinna --=20 Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat --C7zPtVaVf+AK4Oqc Content-Type: application/pgp-signature Content-length: 819 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJT9w/LAAoJEPU2Bp2uRE+gptgP/A26Qa+w5ChZQ5rSqyOUP992 txG7Zbxt4zEpbKvaQSmGJVvOCAUSixNxYRSZuLv+uL94RK4ZtLzUz6t8HCennxBA uYKdABPtncsEsYX3bK+UfSt9rr5lBS4VHFtpKFdQqA37np6WhSZcAPHsNxNh7BZv 2mRhYWf4Q0HvJp0zfLLKx6RAx9+ogk2+x56Z2Eag39QjSxvucP75Se08I7N6p+7m xCjiG2kpLQO949eCpmps4EsP+ey1YBJkg3DS5rH9vR5YNpewCgleKPmQ3Ig7M+Ap oRx/oB1sZwRKloeW65f68WwMpebg/MC6nbVkR3f37XuQsbXRK938IwtUmnau/fK5 PTqJd7TPn5vbmT1gB2kvvU8STzLahZqgmj6VjbIDtTVZpa54WJsAJTvBPS8+shkA +5vdIvKmI/sJMtIP+ZwqdtczfvFEeWfRNoCkXsaau0b38c1Ay5PhCiN8mlt0ISSC ArHGbKXLWm3pN3jb3bWkfBUqCrzNWAcD/0zEBxBn1lvCklK4ST3+R9IsumpiYYCX pWlivscySDjFU+sBuvmHS+XwhxlsNorWOobHOYspsUBFDV10h1lcCllloulB4Xpd sze81S7bLdGhZipIoxt7LnjQ5K4tX67cQNMM4q5fXxbxSQaU6QpgKwa6eERhJGC1 OF0rxEuLGlEBmrilNgNq =UgJh -----END PGP SIGNATURE----- --C7zPtVaVf+AK4Oqc--