timeout in LDAP access
Denis Excoffier
cygwin@Denis-Excoffier.org
Tue Jul 15 16:29:00 GMT 2014
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
More information about the Cygwin
mailing list