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:reply-to:message-id:to:subject
	:in-reply-to:references:mime-version:content-type
	:content-transfer-encoding; q=dns; s=default; b=m8CRhAzY9AhTw+RC
	/KQwzmSzJ7qooWUCvE9PmEuQ+ihSunFZiWVxxTLT3ApXA7vHcFjwoUBfpQyAPYIE
	wrnZ4soYCa9oXmcFapJQGImWlRo7m+KUS4NqGy1ObCqkdWZQ9q3ih9cE1q67nGMJ
	jqq1ekKzgP+3HnROd1s2M0WESnw=
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:reply-to:message-id:to:subject
	:in-reply-to:references:mime-version:content-type
	:content-transfer-encoding; s=default; bh=NPai/adY5VYXzuiPAZjnhv
	ozZuI=; b=NkVtJRwbPErriS/jCs8AIzgxhLbrK0CAbiU4/aQSM7h/CrWJL5DXRW
	fQ/zxLR6UGL6jXK8ARoW4LVf4dhuK/Q70jQv4s/n9aRRzULiSEssRj+HJabXiZEF
	lfa8iJfe7fbkzGSTHCzPmHGWoSpEQmGN/vP/QtI3o8y/mtWmUdh/Q=
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=-3.3 required=5.0 tests=AWL,BAYES_50,FREEMAIL_FROM,KAM_THEBAT,MIME_BASE64_BLANKS,SPF_SOFTFAIL autolearn=no version=3.3.2
X-HELO:	smtpback.ht-systems.ru
Date:	Tue, 15 Jul 2014 22:13:17 +0400
From:	Andrey Repin <anrdaemon AT yandex DOT ru>
Reply-To:	cygwin AT cygwin DOT com
Message-ID:	<76065098.20140715221317@yandex.ru>
To:	Denis Excoffier <cygwin AT Denis-Excoffier DOT org>, cygwin AT cygwin DOT com
Subject:	Re: timeout in LDAP access
In-Reply-To:	<79A8CE40-E412-4479-B058-378823313FA8@Denis-Excoffier.org>
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> <20140714134836 DOT GA2637 AT calimero DOT vinschen DOT de> <79A8CE40-E412-4479-B058-378823313FA8 AT Denis-Excoffier DOT org>
MIME-Version:	1.0
X-IsSubscribed:	yes
X-MIME-Autoconverted:	from base64 to 8bit by delorie.com id s6FIKT9Y014844

Greetings, Denis Excoffier!

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

> Independently, i’m still not sure we have to workaround IT "madness" at all. First, IT
> people might set PosixOffset to 1 for each domain and you cannot catch this kind
> of alternate madness. Also, be sure that if some user someday suffers from a duplicate
> UID situation, this will be reported to them and hopefully addressed (or not because
> this might be expected), but most probably for a single domain. We have to live with
> PosixOffset=0.

I'd say, setting up your AD with zero offset is as bad, as using
192.168.0.1/24 network (or any other well known range) for VPN connections.
I don't think this is a situation that should be attempted to fix from client
side.
What we really need here is a comprehensive explanation of the issue and a
suggested way to remedy it at the root.


--
WBR,
Andrey Repin (anrdaemon AT yandex DOT ru) 15.07.2014, <22:08>

Sorry for my terrible english...

- Raw text -