This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: timeout in LDAP access
- From: Denis Excoffier <cygwin at Denis-Excoffier dot org>
- To: cygwin at cygwin dot com
- Date: Tue, 15 Jul 2014 18:29:32 +0200
- Subject: Re: timeout in LDAP access
- Authentication-results: sourceware.org; auth=none
- 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>
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