From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13859 invoked by alias); 28 Jul 2014 09:21:53 -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 13837 invoked by uid 89); 28 Jul 2014 09:21:52 -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; Mon, 28 Jul 2014 09:21:51 +0000 Received: by calimero.vinschen.de (Postfix, from userid 500) id EECFD8E05FF; Mon, 28 Jul 2014 11:21:48 +0200 (CEST) Date: Mon, 28 Jul 2014 09:21:00 -0000 From: Corinna Vinschen To: cygwin@cygwin.com Subject: Re: timeout in LDAP access Message-ID: <20140728092148.GB25860@calimero.vinschen.de> Reply-To: cygwin@cygwin.com Mail-Followup-To: cygwin@cygwin.com References: <20140707110714.GJ1803@calimero.vinschen.de> <19B9F8D8-7FD6-4A7B-AC83-BBF8D152319D@Denis-Excoffier.org> <20140709101256.GD26447@calimero.vinschen.de> <20140714095107.GB10401@calimero.vinschen.de> <20140714134836.GA2637@calimero.vinschen.de> <79A8CE40-E412-4479-B058-378823313FA8@Denis-Excoffier.org> <20140716135151.GC8520@calimero.vinschen.de> <4457DF49-B4C7-4A7C-A189-AB6F4D94794E@Denis-Excoffier.org> <20140718191819.GH15332@calimero.vinschen.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="f2QGlHpHGjS2mn6Y" Content-Disposition: inline In-Reply-To: <20140718191819.GH15332@calimero.vinschen.de> User-Agent: Mutt/1.5.23 (2014-03-12) X-SW-Source: 2014-07/txt/msg00330.txt.bz2 --f2QGlHpHGjS2mn6Y Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 3792 Ping? On Jul 18 21:18, Corinna Vinschen wrote: > On Jul 17 08:33, Denis Excoffier wrote: > > On 2014-07-16 15:51, Corinna Vinschen wrote: > > > It occured to me that there's another way to do that. The problem > > > you're mentioning above could be alleviated if the first Cygwin proce= ss > > > in a process tree fetches all POSIX offsets of all trusted domains ri= ght > > > at the start, rather than fetching the POSIX offsets only on demand by > > > whatever process needs it. This would slow down the startup of the > > > first process slightly (one LDAP request per trusted domain, but only > > > asking your primary DC), but this would have two advantages: > > >=20 > > > - After fetching all POSIX offsets, we could filter out all POSIX > > > offsets which don't make sense. These would be set using the fake > > > offset setting mechanism. "No sense" would include offsets < 0x1100= 00 > > > or offsets > 0xff000000. If the first process in the tree=20 > > >=20 > > > - The UID/GID values would be stable throughout the process tree. > > >=20 > > > - The UID/GID values would be stable systemwide when utilizing cygser= ver. > > >=20 > > > That's a bit of work, but Cygwin 1.7.31 will still come without this > > > AD integration code anyway, so we still have time to turn everything > > > upside down. > > I buy this of course, but i=E2=80=99m still not convinced that we have = to > > workaround. After all, since i don=E2=80=99t care the other domains in = my daily > > work, i=E2=80=99m not affected at all. Most of the users will never be = affected > > i suppose. And if Cygwin happens to circumvent a null posixOffset by > > providing its own, there will be even less chances for collisions and > > for collisions being reported. > >=20 > > But we can consider the other way and for that i will use a comparison: > > using special characters (like =E2=80=98\n=E2=80=99) gratuitously in th= e middle of filenames > > is usually considered as a bad practice, but always possible by > > doing =E2=80=98char *filename =3D "a\nb"; fopen(filename, "w")=E2=80=99= . Now, once this > > file is created, you can use =E2=80=98ls=E2=80=99 in the folder. Do you= think =E2=80=98ls' > > should respect user decision and display the raw \n in its output or > > try to workaround by using some substitution character (like =E2=80=98?= =E2=80=99) in order > > not to wrap at unexpected locations? The answer is that =E2=80=98ls=E2= =80=99 substitutes > > by default, but also provides a full group of related options to change= this > > behavior (--quoting-style=3DWORD, --hide-control-chars). > >=20 > > Of course, adding options (eg in nsswitch.conf) to orientate the assign= ment > > of posixOffsets to various substitutes would be useless. Even assigning > > the null posixOffsets to non-null values, i=E2=80=99m not convinced of. >=20 > We really should do that to avoid collisions with system accounts, IMHO. >=20 > But maybe we should handle it as a border case of a border case, and > reliably. Rather than using the default fake mechanism, what if > we use default offsets for the two cases: >=20 > Case 1: posix offset is < 0x100000 =3D=3D> Enforce posix 0ffset 0xfe80000 > Case 2: posix offset can't be fetched (this points to a local user > having no access to this kind of domain information) > =3D=3D> Enforce posix offset 0xfe000000. >=20 > This would result in potential collisions in very rare border cases, > but it would result in reliable mappings throught all processes. > And, the complexity would be quite small. any feedback on this one? Shall I create a snapshot with a matching patch? Corinna --=20 Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat --f2QGlHpHGjS2mn6Y Content-Type: application/pgp-signature Content-length: 819 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJT1hYsAAoJEPU2Bp2uRE+gueMP/0ujaTSZfuth3nAIplZt3q8/ SkfJXXiIJnrBfFcV1zu9CrIOcDXa4l81qqvTjhp+/nt0aeoRvcdn5O0eJO/Kqd9l ZcGwN5NVTWUz8Peq1WpK5dZpdh9mWF28y7oxYmtgoopZx5XBDz2DuFL+jXeAbh2r daONgW3jPisw+febTGH/AHP+tychmvLy8I6auvAvkCBzVGcW4XsFazA3FO91MfTN FxI9av1AqjJyXiArE2SZIfRgwAN3jyr1yROYXcFadoHPfxpFkXzFsQoGfvGUrvP2 hhPfiRz/EE8i/n/qYD1yS482AXlMUi/YgKZaU9r2GJ9/9TZkrY232FCI+J2g5gvm XxvG/nwnTaYfdI44IkNm6Wu6ekV4lJc69/7Y5hBz2IRoSGf858jnYJwFLJKPcZmS r9drE10SvIwHoVGDx8ZGtAdEHMMR2DgQZOd1vt06V4W7kqqM4GeCKUJD6l59Bki3 +bzo4Zhv7MMVQsLGK32o5JoSp3CRcCUadY+pFaoPuncMq6KNI3H3seYwCaa9fKrX Lyjk6r0z2W86y9+8hBokiJNpsIt7Jv5t2CHXjNFWhE+uXPf4c8vfsLYKyzs55fwN L0uT/7aDdQlUPCirxukJhJYpKrcoHfwAkk0En+t/+OWbvjgjeNTjctyCpWSh65MY TVk0gbrUZWjyVh/MBjx7 =H7X4 -----END PGP SIGNATURE----- --f2QGlHpHGjS2mn6Y--