X-Recipient:	archive-cygwin AT delorie DOT com
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=
DKIM-Signature:	v=1; a=rsa-sha1; c=relaxed; 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; s=default;
	bh=Es8ZWZ8HsMJSd/OwQcQ5PeYXUss=; b=dfurPmkzxpES3z2VeQ2rGAi7PvCy
	pvYw6R+lcfP59s6RNXM771tKaHiZsalZyjsggX01uT8aUc524Lc4lZSRGIv3XPqd
	bPVtgLxMIKHrZhYQd8mnQW+gBOrzxeGG+TEInTTQcaSX2LORdmqcCtaWzTLba0DU
	WN4LQxr5kAGnqYs=
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
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
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
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--

- Raw text -