From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 71867 invoked by alias); 12 Jan 2017 22:13:29 -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 71847 invoked by uid 89); 12 Jan 2017 22:13:28 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-100.3 required=5.0 tests=AWL,BAYES_05,GOOD_FROM_CORINNA_CYGWIN,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=Ultimately, mulling, Exchange, H*MI:sk:8zg@mai X-HELO: drew.franken.de Received: from mail-n.franken.de (HELO drew.franken.de) (193.175.24.27) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 12 Jan 2017 22:13:27 +0000 Received: from aqua.hirmke.de (aquarius.franken.de [193.175.24.89]) (Authenticated sender: aquarius) by mail-n.franken.de (Postfix) with ESMTPSA id 58609721E281E for ; Thu, 12 Jan 2017 23:13:24 +0100 (CET) Received: from calimero.vinschen.de (calimero.vinschen.de [192.168.129.6]) by aqua.hirmke.de (Postfix) with ESMTP id A0CD55E021D for ; Thu, 12 Jan 2017 23:13:23 +0100 (CET) Received: by calimero.vinschen.de (Postfix, from userid 500) id 82AC8A804D6; Thu, 12 Jan 2017 23:13:23 +0100 (CET) Date: Thu, 12 Jan 2017 22:13:00 -0000 From: Corinna Vinschen To: cygwin@cygwin.com Subject: Re: Hangs on connect to UNIX socket being listened on in the same process (was: Cygwin hanging in pselect) Message-ID: <20170112221323.GE23119@calimero.vinschen.de> Reply-To: cygwin@cygwin.com Mail-Followup-To: cygwin@cygwin.com References: <20170109141306.GB843@calimero.vinschen.de> <20170109171635.GB26337@calimero.vinschen.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="19uQFt6ulqmgNgg1" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.1 (2016-10-04) X-SW-Source: 2017-01/txt/msg00133.txt.bz2 --19uQFt6ulqmgNgg1 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 2974 On Jan 12 11:59, Erik Bray wrote: > On Mon, Jan 9, 2017 at 6:16 PM, Corinna Vinschen wrote: > > Right. A better solution for the problem would be nice. Ultimately > > we want to check if the other side of the socket is actually a Cygwin > > process which knows the secret, not a stray native Windows process > > which accidentally hopped on the bandwagon, and we want to exchange > > the credentials so a subsequent SO_PEERCRED call returns correct values. >=20 > Ah, okay. I found the original thread you mentioned, and I see that > you sort of discussed some possibilities but nothing was quite > satisfactory at the time, and it was dropped--you mentioned some idea > about exchanging information via pipes, but that was a bit complicated > and half-baked. >=20 > Christian described a scheme in that thread which at least seemed like > a way out of the connect hanging problem, and also improved the > security (I think) by having separate server and client secrets, so > that a malicious server could not gain the socket secret from the > client. But he also worried: >=20 > > The only drawback which remains is that the client performs the send() > > before first recv() unconditionally. It will realize the bad server sec= ret > > lately on first recv(). >=20 > Though you wrote: >=20 > > Yeah, but it might be better than nothing and if it avoids the hangs, > > even better. >=20 > Which is sort of how I feel, though I do appreciate the security > implication. I'm not sure there actually are security implications. AF_LOCAL sockets are local only, no network access. And every Cygwin process knowing the name of the socket file and having sufficient permisson to read the file can connect. And even a non-Cygwin process written by someone who knows how Cygwin AF_LOCAL sockets work. It's open source after all. What this method mainly solves is to make reasonably sure that the peers are actually Cygwin processes on both sides which know that this is an AF_INET socket emulating an AF_LOCAL socket. Plus SO_PEERCRED emulation, but that's another problem just attached to the original handshake. Maybe we need to take a step back and just consider for a while what we want: Step 1: Make sure with whatever method that the process on the other side is actually a Cygwin process opening this socket as an AF_LOCAL socket. Step 2: Exchange SO_PEERCRED information. Step 3: If we did it really intelligent, maybe we finally also have a method to implement descriptor passing. Finally. After all these years. And maybe, we should not actually use the socket itself to exchange the information but rather create some kind of side-channle for that. Especially in terms of step 3, I'm mulling over this for years now and always something else got in the way and had to be done first. Corinna --=20 Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat --19uQFt6ulqmgNgg1 Content-Type: application/pgp-signature; name="signature.asc" Content-length: 819 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJYd/+DAAoJEPU2Bp2uRE+g8ycP/3tIetDcS7kia+ls5vdZFtUF RZjALT4iMlVQ/sGLVvDYqqe2W3QTrY1FgQ6Lm7IpYGe0qbhRWuCGW4GFd9DLv8Z+ A8WUXcN4e/wHaSjsUHIJsREP8EUg5Dw93bUL5N98t/h5TBMv89VkZ3MtuRmL/xUv 7jLREmoWSRQcnl4T9fGzx+LFEajVXNixIfdjtNs0TdalegJQSpNX2X1i5eFqazhd LBFAr6Mb7w+Sw6FD8mkNf0ZiNAZMygahnRDaC+D/xp3t/3FtCYOVXj7Cxzrn9rms lxYspgYfaDg0HHpsFD8Z4qM3MdJgxWEpnvBEKrbovZiYw0RGzCJ7lo+G26JFlbV2 WSjlxN4qFcAb3Y0E/wZzfUC+0VGz51zB2AormW73ZpjpKMrSMfFsPOYRWOPw97qr 7Nu69gD+hfpUzul1zrXBI8u5+kKCfiO7tBZXluQPd8naHfE+59R3LB1MUiCSfMo9 vO5tetDOyusf5YAVScgax3TTCd+G9k2OYEo6CUKWR8SXiVOJa6F4Zgta2BxAPe39 AAWMiq6dtCRu9tV3acwd0rX8AzSkrsDeAAMiEP3NZVETOy+k91/41WOayY6GzFD4 YDqqALCI5n9yP/e0Nv4e7AunLJH+S8f8EEuqj0zE7UO5IonSjTt2RqbPYl49eVXG 5WeB+td7DbF+y+R3RJSI =XG7o -----END PGP SIGNATURE----- --19uQFt6ulqmgNgg1--