[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Is existing documentation kind of vague?



MJ J wrote:
> Client apps are not scoped to do subtree searches from the root of the
> directory where the autoincrement objects live, nor do the ACLs permit
> it, but you knew that already.

Good to hear it's alright in your deployment.
But please add this extra note next time you give general advice to others.

> Duplicate a race condition using the above code and you shouldn't be
> using LDAP in the first place.

Did you really read what I wrote? Did you look at RFC 4527?

Ciao, Michael.

> On Tue, Nov 14, 2017 at 10:26 PM, Michael Ströder <michael@stroeder.com> wrote:
>> MJ J wrote:
>>> You don't need a special object class or schema, you can use this:
>>> dn: cn=user,ou=increment,dc=foo,dc=bar
>>> objectClass: top
>>> objectClass: account
>>> objectClass: posixAccount
>>
>> Ouch! Depending on the config of your LDAP server and client systems
>> this is a visible user account with username 'user' and *changing* and
>> *conflicting* uidNumber. This is bad design. No wonder if you're running
>> into problems with nss-pam-ldapd (nslcd) or sssd later.
>>
>> You have been warned.
>>
>>> And here is a python method to do the job for you:
>>>
>>> def increment_uidnumber(l, base):
>>>     """ Perform LDAP modify-increment operation on uidNumber tracking object """
>>>     modlist = [(ldap.MOD_INCREMENT, "uidNumber", "1")]
>>>     l.modify_s("cn=user,{0}".format(base), modlist)
>>>     r = l.search_s(base, ldap.SCOPE_SUBTREE, "(objectClass=posixAccount)",
>>>                    ['uidNumber'])
>>>     next_number = r[0][1]['uidNumber'][0]
>>>
>>>     return next_number
>>
>> Using MOD_INCREMENT is good but the above read-after-write is prone to
>> race conditions. Since you're using Python you can look at file
>> Demo/pyasn1/readentrycontrol.py to learn how to use the PreReadControl
>> or PostReadControl class (see also RFC 4527) for incrementing *and*
>> reading the new ID within a single atomic modify operation.
>>
>> Also note that you should only do this on a single provider or "primary"
>> MMR-enabled provider (ITS#8757 would be nice for that).
>>
>> BTW: That's how it's done in Æ-DIR but with a special object class:
>>
>> https://demo.ae-dir.com/web2ldap?ldapi://%2Fopt%2Fae-dir%2Frun%2Fslapd%2Fldapi/ou=ae-dir??base??bindname=aead,X-BINDPW=CorrectHorseBatteryStaple
>>
>> One of the unsolved problems is that IDs consumed from the pool might
>> not really be used by the client application possibly resulting in gaps
>> in your ID space.
>>
>> Ciao, Michael.

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature