DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:date:from:to:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; q=dns; s=
	default; b=OZu8tgOCVf6bVQyvGefBeRqE6vz5Z9tFuW9uwKaJQnGDhqE8fPqic
	YwaJ/XhapvqoFxnJ8qFLzY9F6i4eG2FDBv42RpB/K6q4ao7nEJrEYEBAx1A/Uz9x
	3TUyMADUDF20No8j2c97umIpZLf/TOl4NXBYv82x7hklA79VxgGijE=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Date: Fri, 22 Aug 2014 22:16:22 +0200
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: connect() hangs on a listen()ing AF_UNIX socket
Message-ID: <20140822201622.GM32314@calimero.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <53F61B70 DOT 2020600 AT t-online DOT de> <20140821164402 DOT GB21065 AT calimero DOT vinschen DOT de> <53F6450C DOT 3070007 AT t-online DOT de> <20140822093923 DOT GA12878 AT calimero DOT vinschen DOT de> <53F78CB1 DOT 9080406 AT t-online DOT 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)

--DfnuYBTqzt7sVGu3
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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

-----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--