From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20262 invoked by alias); 18 Oct 2014 10:35:58 -0000 Mailing-List: contact cygwin-developers-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-developers-owner@cygwin.com Mail-Followup-To: cygwin-developers@cygwin.com Received: (qmail 20246 invoked by uid 89); 18 Oct 2014 10:35:57 -0000 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 Received: from aquarius.hirmke.de (HELO calimero.vinschen.de) (217.91.18.234) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 18 Oct 2014 10:35:56 +0000 Received: by calimero.vinschen.de (Postfix, from userid 500) id 779A48E14F0; Sat, 18 Oct 2014 12:35:53 +0200 (CEST) Date: Sat, 18 Oct 2014 10:35:00 -0000 From: Corinna Vinschen To: cygwin-developers@cygwin.com Subject: Re: Cygwin AF_UNIX emulation Message-ID: <20141018103553.GW2681@calimero.vinschen.de> Reply-To: cygwin-developers@cygwin.com Mail-Followup-To: cygwin-developers@cygwin.com References: <544039E2.2040908@t-online.de> <20141017114911.GA27069@calimero.vinschen.de> <54416E01.70309@t-online.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ZgsjCHEQV+PhxuqO" Content-Disposition: inline In-Reply-To: <54416E01.70309@t-online.de> User-Agent: Mutt/1.5.23 (2014-03-12) X-SW-Source: 2014-10/txt/msg00009.txt.bz2 --ZgsjCHEQV+PhxuqO Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 4353 On Oct 17 21:29, Christian Franke wrote: > Corinna Vinschen wrote: > >On Oct 16 23:34, Christian Franke wrote: > >>Nasty detail: At least postfix sets the all AF_UNIX sockets to rw-rw-rw= - and > >>relies only on directory permissions (private: rwx------, public: rwx--= x---) > >>for access control. This is not effective on Cygwin. Due to the rw-rw-r= w-, > >>the 'secret' is world readable on Cygwin and another Cygwin specific pa= tch > >>is required :-) > >Yeah, thanks to Windows which enables the "Bypass Traverse checking" > >privilege for everyone :( At one point in 2005 I toyed with traverse > >checking but eventually gave up in 2006 and reverted the stuff. >=20 > This does not appear as an Se*Privilege in the token, correct? It's in the token, and it's an ugly amalgamation of two unrelated mechanisms(*): SE_CHANGE_NOTIFY_NAME Required to receive notifications of changes to files or directories. This privilege also causes the system to skip all traversal access checks. It is enabled by default for all users. User Right: Bypass traverse checking. > Any idea why this was added for everyone? It's in there and set by default since the dawn of (NT) time, probably for the notifications to work, and as a side-effect, being faster. > >In theory, a malicious server could wait for the client package and > >read the content, thus it knows the socket secret and send its own > >package with the secret gained from the client. >=20 > That's exactly why the server bind() should write two independent secrets= to > the file. Receiving the secret from the client does not help the attacker= to > fake the server secret then. >=20 > The only drawback which remains is that the client performs the send() > before first recv() unconditionally. It will realize the bad server secret > lately on first recv(). Yeah, but it might be better than nothing and if it avoids the hangs, even better. > >Btw., considering my change to call the connect side of the handshake > >only when an FD_CONNECT arrives, what exactly is postfix still missing? > >[...] >=20 > With 20141014 snapshot, it hangs in poll({client_sd, POLLOUT}, 1, -1) aft= er > a nonblocking connect() and could not be kill()ed. >=20 > postfix master unconditionally starts up some services like qmgr and pick= up > by connecting to itself: >=20 > bind(listen_sd, "public/pickup") > listen(listen_sd, .); >=20 > set_nonblocking(client_sd); > // Cygwin 1.7.32-1 hangs here: > connect(client_sd, "public/pickup"); > // Snapshot 20141014 hangs here: > poll({client_sd, POLLOUT}, 1, -1) Oh, ok. The FD_CONNECT handling just moved the hanging to a later call to wait_for_events. Sigh. > BTW: I could ITP postfix in one week or so. It would rely on the SO_PEERC= RED > workaround for now. Any objections? Uh, we're not having a Cygwin release it could work with for now. It might be better to wait until then, if that's ok with you. I'm planning to release 1.7.33(**) in November at the latest. I'm not going to stall this release until we have another solution for the aforementioned problems, the SO_PEERCRED wourkaround should suffice for now. > >Independently of that, I'm mulling over the idea to introduce a > >sidechannel via pipe. >=20 > Hmm... sounds promising. ...and like a lot of work. Any other, simpler idea welcome. Btw., I'm also just looking into the WSAAccept and WSAConnect functions. These functions provide a way to submit application controlled connect data in a handshake-like operation, and they are supposed to work with non-blocking sockets. Maybe these functions would work for us? Also, starting with Windows Vista there is a function WSAImpersonateSocketPeer. Yes, really. Maybe that's a way out, which would also leave Windows XP/2003 behind. Given that XP is out of support now, and given that 2K3 goes out of support next April, I'd not be overly concerned. Corinna (*) http://msdn.microsoft.com/en-us/library/windows/desktop/bb530716%28v= =3Dvs.85%29.aspx (**) Or 1.9.0. I'm not sure yet if we should bump the DLL major version due to the massive changes to user and group handling or not. --=20 Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat --ZgsjCHEQV+PhxuqO Content-Type: application/pgp-signature Content-length: 819 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJUQkKJAAoJEPU2Bp2uRE+gqDoP/1iq9xItBUrPjTSa/HI0NvuT KXXvLnYnwWjB27rdnSzed5bUF+wv6pa48ddB4D+rtNdc+b4WSL1VG4n3uNGgFb6/ SHn9x5Up90VV46JyQZbDwmAbRNf1xwXmkztb7FwOmVOWJp1nRNWLBhjikcjWjdDl xfcb1og1wB4DLyCdr3ER+NqbhAD+OBfNULaan0E+GHDsAAQ7xrAdQrXPlfkQ6XaC n0QHSYhTDNLdDlCtA+oczLhLBpeiu6Ngd3DPewAY+mn+W3GeZu3cBHMjRy4wucoo PVOGpFYad5SnsRsrsuEgA7SgH3lYa/AOkcnz6JgvcJGh1ct4xM6sK3bgufU9Kwov hbdOIupVuUZgBxKMURNXAvXWd73LILYY/warVJWE9uGzuW6Qxplj4j8J7b3tkzxd KKKHh88dhhOL3c50kwKDsLqmu97U8Jy8q9rMeb2Q9eCmauko/II9/IbM3vozM08p oEt1g6OXieP0hLSf3gq1tIU0b41otQmn3NyqUFYz4gwPuhysDpVGel/Wl4ag1QG5 +vz3tVBY3ZpYvkCBU4ZNNCvrWXSs6QK9BL14LIc0A2t28QT17h6hLBGYh7GAYc9O J/9LTF74ExGwVOpKdcFzUcM2NJ1SSDAuU78Lz4aP9XPvZhFkEhSAfoONdenFRH4G VXa8TRHPuEGf7K1WG8HN =gwH1 -----END PGP SIGNATURE----- --ZgsjCHEQV+PhxuqO--