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: List-Subscribe: List-Archive: List-Post: List-Help: , 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 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> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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