Re: Is existing documentation kind of vague?

[MJ J <mikedotjackson@gmail.com>]

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.

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



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.
>