Univention Bugzilla – Bug 54410
Make udm allocation of uidNumber/gidNumber atomic
Last modified: 2023-03-02 18:22:04 CET
We could replace the current UDM allocator code for uidNumber/gidNumber by an atomic operation using an LDAP MOD_INCREMENT and Post-Read-Control.
A little bit context: In UDM we have allocators.aquireRange() which searches (in case of uidNumber and gidNumber) for already used values/ID's from a starting number (e.g. 65536) until a end number (e.g. 1000000) and uses the first free found number to use that for newly created objects. The starting number is cached in the `univentionLastUsedValue` attribute of e.g. the cn=uidNumber,cn=temporary,cn=univention object. So the allocation of a new free uidNumber usually takes 1 or 2 searches. There is a DoS vector described in another bug, when setting the univentionLastUsedValue to something smaller than the range-start. In that case the number of searches done is increased by how many ID's already exists from the start of the range. A alternative approach from Michael to simplify the mechanism: Search via server side sorting by sorting descending by ID with a limit of 1 result. So we would get rid of the LastUsedValue caching. But then there could also be gaps for manual set high ID's.
On a customers test system the univentionLastUsedValue isn't updated anymore (so far it's unclear why, it might be related to customer specific changes) Never the less I ended up taking a quick look at this... The server side sorting approach works in theory. Enable it in /etc/ldap/slapd.conf: ``` moduleload sssvlv.so overlay sssvlv ``` Search: univention-ldapsearch -E "sss=-uidNumber:2.5.13.15" -z 1 "(uidNumber=*)" uidNumber dn But it doesn't seem to scale. In my test ldap with around 300000 objects that search took around 20s :( I like Arvids idea, calling MOD_INCREMENT on univentionLastUsedValue and get the new value with Post-Read-Control.