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