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:content-type:mime-version:subject:from
	:in-reply-to:date:content-transfer-encoding:message-id
	:references:to; q=dns; s=default; b=Eycbpd5xlDqWlNkP/EWFztbqxbDP
	rDgvBfn4q5RJpHLGOM9Z2ElsKUkqNsRyodECZP/RrgSTLxyV/1+vSEaJlq4OoE4T
	6uaxXtQwJH5b1yAJvSTBbg/VSl3AgBahlyoBH09i9FJb/WdxWE8h9f/rJjyhRzij
	0atRpLvXQYGSVNw=
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:content-type:mime-version:subject:from
	:in-reply-to:date:content-transfer-encoding:message-id
	:references:to; s=default; bh=+RpN9OTN8AgYlXhWK/xMbEX9KLg=; b=WN
	AdN0f8JBoSFzP6/PKSY3DkkUry9VGMq+iffyPYSePeRoKWEiSeLcWg0If0GSirgd
	XVcbVIiNfa2IRyg6VnR2BdP24JbfAlH5STlX4sqyRi9TCztGVMQEHR2d20ZEazck
	QwN3JmboPHfK6J7+V+MJvK/MsccNv7ttDM9/TxJ7M=
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=-1.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2
X-HELO: smtp4-g21.free.fr
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Subject: Re: timeout in LDAP access
From: Denis Excoffier <cygwin AT Denis-Excoffier DOT org>
In-Reply-To: <20140714134836.GA2637@calimero.vinschen.de>
Date: Tue, 15 Jul 2014 18:29:32 +0200
Message-Id: <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>
To: cygwin AT cygwin DOT com
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id s6FGTruL009358

On 2014-07-14 15:48 Corinna Vinschen wrote:
> 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:
>>>>> 
>>>>> 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.
>>>> 
>>>> Ouch.  Why on earth are admins doing this?  There's no way to
>>>> workaround this reliably.
>>>> 
>>> Reliably i don’t know. I’ve modified uinfo.cc in order that the special value
>>> for td->PosixOffset is no longer 0. Taking into account that LDAP_SERVER_DOWN
>>> is now recognized, my ‘getent passwd’ executes gracefully in 40 minutes
>>> (instead of 60) and ‘getent group’ in 25 minutes (instead of 90). Also quicker
>>> is ‘mkpasswd -d secondary_domain’ of course. Patch attached.
>> 
>> 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.
>> 
>> 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.
>> 
>> There are two ways to workaround that.
>> 
>> - The better solution is to inform your IT of the problem.
>> 
>> - 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.
Tried and it works as expected. However there is a design bug. Suppose you
have a SID from a non-primary domain (with PosixOffset=0). When you enumerate,
you get a PosixOffset that takes into account the previously encountered
secondary domains with PosixOffset=0, say you get UNIX_POSIX_OFFSET-3*0x00800000

But you can also jump directly to the non-primary domain of this SID, eg by
‘getent passwd SID’. In this case you get UNIX_POSIX_OFFSET-0x00800000.

In fact, real code is a little bit more complex, but you get the point:
‘getent passwd’ and ‘getent passwd SID’ will not give the same UID for a given SID,
the AD remaining unmodified.

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.

Yet, under the assumption that PosixOffsets are not modified by Cygwin, previous
uinfo.cc (snapshot dated 20140709) is not so efficient when
PosixOffset=0 (eg too many connect’s), and i think my patch makes a better Cygwin
than with no patch. Probably it can also be improved to remove the special value.

Regards,

Denis Excoffier.

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple