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=U5Vf1IMOj97Hh6wh299tk9eQcCqhp3TboRk0N7euODCB2AmIwOOKD
	utJBOX+SB1gb16xm8y80I/5M63sR182M6NXROJnjB3MnzO1I8OMJd1d7T/EJJEKx
	XIPWevpdLokPV903wy5rbRY21kQnrMUbCOv8I4Lx0qvTSYhMemT/JA=
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=FFlQcQ6YluYOGek+As+h4XAC5cI=; b=BnMHLa2kTuhzlejtFwE6lDtotVNk
	WU+toNQP8aDI/nC5tjsiK1eax85GF6DRO2fWmrga5jNMeQoIDWzGVt+xapNW7Rr4
	BPyUDebJ4arV2/S01cRAv7IKO2TP9DtiWOINBgb+wZ3nKkfMeFmmEMajjznTjysE
	JI/+nPGv7vdyKFU=
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=-5.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.2
X-HELO:	calimero.vinschen.de
Date:	Mon, 14 Jul 2014 15:48:36 +0200
From:	Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To:	cygwin AT cygwin DOT com
Subject:	Re: timeout in LDAP access
Message-ID:	<20140714134836.GA2637@calimero.vinschen.de>
Reply-To:	cygwin AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
References:	<20140624155851 DOT GJ1803 AT calimero DOT vinschen DOT de> <20140625101526 DOT GO1803 AT calimero DOT vinschen DOT de> <E760D646-FFCB-434C-B990-7783DC011326 AT Denis-Excoffier DOT org> <20140625211355 DOT GA25116 AT calimero DOT vinschen DOT de> <E3509AAC-C4A0-4293-988F-E94BF2421180 AT free DOT fr> <20140707110714 DOT GJ1803 AT calimero DOT vinschen DOT de> <19B9F8D8-7FD6-4A7B-AC83-BBF8D152319D AT Denis-Excoffier DOT org> <20140709101256 DOT GD26447 AT calimero DOT vinschen DOT de> <BA09D7D8-96E6-431F-9434-8BA8A2AB4952 AT Denis-Excoffier DOT org> <20140714095107 DOT GB10401 AT calimero DOT vinschen DOT de>
MIME-Version:	1.0
In-Reply-To:	<20140714095107.GB10401@calimero.vinschen.de>
User-Agent:	Mutt/1.5.23 (2014-03-12)

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

On Jul 14 11:51, Corinna Vinschen wrote:
> On Jul 12 15:39, Denis Excoffier wrote:
> > On 2014-07-09 12:12 Corinna Vinschen wrote:
> > >>=20
> > >> I have encountered this case in real life. The domain admins have set
> > >> the trustPosixOffset of the secondary domain to zero. This value is =
therefore
> > >> never recorded and the cldap->open occurs again and again.
> > >=20
> > > Ouch.  Why on earth are admins doing this?  There's no way to
> > > workaround this reliably.
> > >=20
> > Reliably i don=E2=80=99t know. I=E2=80=99ve modified uinfo.cc in order =
that the special value
> > for td->PosixOffset is no longer 0. Taking into account that LDAP_SERVE=
R_DOWN
> > is now recognized, my =E2=80=98getent passwd=E2=80=99 executes graceful=
ly in 40 minutes
> > (instead of 60) and =E2=80=98getent group=E2=80=99 in 25 minutes (inste=
ad of 90). Also quicker
> > is =E2=80=98mkpasswd -d secondary_domain=E2=80=99 of course. Patch atta=
ched.
>=20
> That won't work.  It works around your immediate problem by defining
> a non-0 start value, no doubt about that, but it doesn't fix the
> underlying problem.
>=20
> A POSIX offset of 0 is bad.  If other trusted domains have no functional
> POSIX offset value, but are set to 0 instead, they won't have different
> UID values for accounts of different domains.  Two users from different
> domains, both with RID 1000 will both have UID 1000 in Cygwin.  Also,
> the lower UID numbers are reserved for special accounts.
>=20
> There is no guarantee that there won't be a collision at some point of
> the 32 bit UID spectrum, but a POSIX offset of 0 will almost guarantee
> the collision.
>=20
> There are two ways to workaround that.
>=20
> - The better solution is to inform your IT of the problem.
>=20
> - The not so well one is to enhance /etc/nsswitch.conf to allow to
>   define POSIX offsets for domains indepedent of the AD setting.

I tried the third solution for the time being, which is, generating the
fake POSIX offset a bit differently.  Fake offsets are a bit dangerous
in that there's no guarantee that you get a stable mapping between SID
and UID/GID, but it's *hopefully* a border situation we're trying to
workaround.  Please give the latest developer snashot from
http://cygwin.com/snapshots/ a try.


Thanks,
Corinna

--=20
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

--wRRV7LY7NUeQGEoC
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJTw9+0AAoJEPU2Bp2uRE+gyg0P/2OiUKDqXDPdymY0vXXuXrQ/
eDJx1Dve8J9jGbvZeOzrA2STikLPlid5oeeOEbTJFlqtgUtNZnt5MNes4mwce+8X
e8nRZkyro3XS+CjAM5uUqE1Ycp75o2uie9pNU0zLgwLotxFFpgj6MxEIg1hws5lb
NEexVlr3sneNXc3RKM3aYQ2Fv2xeGtw/ff17Zs6bq+NZKKpkU84PGPwNzUTBicuT
sJjRTmyFXliRPMVtv56sR8cJlxCUPD0qiVb30ps3eVTH360d08Gb2Z7/7ZyBaijR
L6domHZyuuMHgbiXiq3qh/vEZdV36GS4BqBAoSvWddxa/27WyORb9/Ue7KMvON6k
ojqSv30wN/62DdHeYkUmFvpyNrJNOT15kjzMsbKKxfS/KRK45zDkonNAvgftfEJs
QtzxkyynbI0Or8IILPfuZCDLIXXTGdqTqLCJvOjFG5AqHZQwXB7UHWT376xSDRSe
fWtFl/etYtB41sRMA+kKbsVhIbkZuaHsyy6iqV+1aP7VmkO03+OER2YcVN/hpyel
AzJUnmbHkgJtL0TEehkh5XWIEkVR6SevDtzRr4cDQetZSyVurqPnd+gOjPQ6koWq
Nh3qdpUUj3/pZeAco62xOFx1OLRqLLHmRDgHYLchwDwiueVMrSQ6qUVrCiOW6FvA
us/kA+OB/j5voZynexSJ
=aXav
-----END PGP SIGNATURE-----

--wRRV7LY7NUeQGEoC--

- Raw text -