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=Re9gaSBRZAAsaB6k2eXgT4c/doHJOfH6GtgKNjs2bvqH9GlCeoSSp
	DT09zzkT+F5ZRS6/IE0TD5SDlpCJg44GtJiwV4/aNzMX/6gA3nd7v/Z30USaGKY0
	Ac0MDBRRWG+jGgk0ZZKwjhH37iScM/DNzZfQNcCEWJzvj+B25C969c=
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=YTHb4htu2z6EHmHSAxO6h2ebcbY=; b=YY8jzn0MoeTE30DRrvXTBFrsNTLx
	qQjrM3eAklWJKxLEMfTfJ3uVnTooJBdAQYmLYCoup7i7dgaMw8ObnSv/Xzf7PNOU
	UwE7MnrtUdcwk+kxdoRcmRw9dDr1JpTe3rqKC9ayXcwkH3pwaigV3ayCo0bkhvwR
	ZIHIb7HK2eRBzwM=
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=-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 AT mai
X-HELO: drew.franken.de
Date: Thu, 12 Jan 2017 23:13:23 +0100
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT 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 AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <CAOTD34aMu6DLP-8kaRXZRoihGxW9Jusf1pDBeM3cTWeNRfLVWw AT mail DOT gmail DOT com> <20170109141306 DOT GB843 AT calimero DOT vinschen DOT de> <CAOTD34b-h4WyYiUtA8sizN6riPe1YsDWdaypDNbODC71xv13UQ AT mail DOT gmail DOT com> <20170109171635 DOT GB26337 AT calimero DOT vinschen DOT de> <CAOTD34YeJJc_YXnWBq0HJou5Ka5Cj+qTRd+BgUti0hdzSX=8zg AT mail DOT gmail DOT com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;	protocol="application/pgp-signature"; boundary="19uQFt6ulqmgNgg1"
Content-Disposition: inline
In-Reply-To: <CAOTD34YeJJc_YXnWBq0HJou5Ka5Cj+qTRd+BgUti0hdzSX=8zg@mail.gmail.com>
User-Agent: Mutt/1.7.1 (2016-10-04)

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

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"

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