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:message-id:date:from:mime-version:to:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	q=dns; s=default; b=xfTPpKkVjqgLE2w3qSlg+NiAmI9B2jVtxZMW44Pf4Ns
	uaYw++E0hSJgyf75FiHbmM8KijuwGWqxefLGNJo/W0t++l4c6xpbIquT/nsImdFH
	j8+4iMTYrZ6lxheTQ4vkQH0IQtAQkCTCTrMOEf9GecQw/CD3cZFKcN+oGvIp52yo
	=
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:message-id:date:from:mime-version:to:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	s=default; bh=huTeitYgsvTvbwMHWeaFvq2qG5Y=; b=RQ9d19h9j9kTVIcn8
	yyig6/dPdjl92JlLA6qORvSxXv6XHzclR7ego3gq3iIDbyPrMh83FGKMbOi9cCT+
	1t1dumVKjRqw8QfRLw76pxKYwM54aeW27lhKGnH2w7ILY1SpbnUDhIPjNKGgQmxQ
	rJAp5a1N8N0OAkmq2oJI10qCp0=
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=-1.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD autolearn=ham version=3.3.2
X-HELO:	mailout02.t-online.de
Message-ID:	<53F78CB1.9080406@t-online.de>
Date:	Fri, 22 Aug 2014 20:32:17 +0200
From:	Christian Franke <Christian DOT Franke AT t-online DOT de>
User-Agent:	Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20100101 Firefox/29.0 SeaMonkey/2.26.1
MIME-Version:	1.0
To:	cygwin AT cygwin DOT com
Subject:	Re: connect() hangs on a listen()ing AF_UNIX socket
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>
In-Reply-To:	<20140822093923.GA12878@calimero.vinschen.de>
X-IsSubscribed:	yes

Corinna Vinschen wrote:
> On Aug 21 21:14, Christian Franke wrote:
>> ...
>> 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.

Which would require to pass an accept()ed handle from parent to 
(grand)child. Let's forget this option for now.


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

Good question.


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

Is an actual handshake really required? It would possibly be sufficient 
that each peer sends its secret+credential and then expects a correct 
secret+credential from the other peer before sending anything.

After actual connect()/accept():

send our secret+cred (should not block due to TCP queuing).
if (! nonblocking recv peer secret+cred)
   set_state(connected_but_secret_missing)
else
   set_state(connected)


Before actual send()/recv()/getpeerid():

if (state == connected_but_secret_missing) {
   if (! recv peer secret+cred)
     abort_connection(ECONNRESET)
   else
     set_state(connected)
}


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() 
wait for server accept().

Christian


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

- Raw text -