(ITS#9486) slapo-unique spins its wheels on a non-trivial olcUniqueURI spec - openldap-bugs

13 Sep 2019


      Full_Name: Norman Gray
Version: 2.4.48
OS: FreeBSD 12.0
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (130.209.45.140)
A plausible-looking spec in olcUniqueURI causes slapadd to spin its wheels
indefinitely.
I want to specify something like:
dn: olcOverlay=unique,olcDatabase={1}mdb,cn=config
    objectClass: olcOverlayConfig
    objectClass: olcUniqueConfig
    olcOverlay: unique
    olcUniqueURI: ldap:///ou=dept-A,o=example?uidnumber?sub
      ldap:///ou=dept-B,o=example?uidnumber?sub
If I do this, however, then slapadd spins its wheels when the `slapd.ldif` is
loaded into an otherwise empty configuration (ie, this happens at configuration
time, before any records/objects are loaded):
$ rm -R /usr/local/etc/openldap/slapd.d/*
    $ su -m ldap -c "slapadd -d255 -n 0 -F /usr/local/etc/openldap/slapd.d -l
/usr/local/etc/openldap/slapd.ldif"
    ...
    ...
    5d77d377 >>> dnPrettyNormal:
<olcOverlay=unique,olcDatabase={1}mdb,cn=config>
    5d77d377 <<< dnPrettyNormal:
<olcOverlay=unique,olcDatabase={1}mdb,cn=config>,
<olcOverlay=unique,olcDatabase={1}mdb,cn=config>
    5d77d377 <= str2entry(olcOverlay=unique,olcDatabase={1}mdb,cn=config) ->
0x800d4eca8
    5d77d377 oc_check_required entry
(olcOverlay=unique,olcDatabase={1}mdb,cn=config), objectClass "olcUniqueConfig"
    5d77d377 oc_check_allowed type "objectClass"
    5d77d377 oc_check_allowed type "olcOverlay"
    5d77d377 oc_check_allowed type "olcUniqueURI"
    5d77d377 oc_check_allowed type "structuralObjectClass"
    5d77d377 >>> dnNormalize: <olcOverlay={1}unique>
    5d77d377 <<< dnNormalize: <olcOverlay={1}unique>
    5d77d377 ==> unique_db_init
    5d77d377 ==> unique_new_domain ldap:///ou=dept-A,o=example?uidnumber?sub
ldap:///ou=dept-B,o=example?uidnumber?sub
    5d77d377 >>> dnPrettyNormal: <ou=dept-A,o=example>
    5d77d377 <<< dnPrettyNormal: <ou=dept-A,o=example>, <ou=dept-A,o=example>
    5d77d377 >>> dnPrettyNormal: <ou=dept-B,o=example>
    5d77d377 <<< dnPrettyNormal: <ou=dept-B,o=example>, <ou=dept-B,o=example>
    5d77d377 >>> dnPrettyNormal: <ou=dept-B,o=example>
    5d77d377 <<< dnPrettyNormal: <ou=dept-B,o=example>, <ou=dept-B,o=example>
    5d77d377 >>> dnPrettyNormal: <ou=dept-B,o=example>
    5d77d377 <<< dnPrettyNormal: <ou=dept-B,o=example>, <ou=dept-B,o=example>
    5d77d377 >>> dnPrettyNormal: <ou=dept-B,o=example>
    5d77d377 <<< dnPrettyNormal: <ou=dept-B,o=example>, <ou=dept-B,o=example>
    5d77d377 >>> dnPrettyNormal: <ou=dept-B,o=example>
    5d77d377 <<< dnPrettyNormal: <ou=dept-B,o=example>, <ou=dept-B,o=example>
    ...
    ^C
and so on and on and on, apparently indefinitely.
The idea is that the uidnumber attribute should be unique across the two OUs,
ou=dept-A and ou=dept-B.  Whether or not this is a valid spec is another issue;
even if it's invalid, it shouldn't cause this behaviour; if the spec is invalid,
it should produce a terminal error.
Looking at the code in servers/slapd/overlays/unique.c, nothing leaps out as an
obvious error (ie, I'm not claiming I have a fix for this).
There was a brief thread about this on openldap-technical:
https://www.openldap.org/lists/openldap-technical/201909/msg00031.html
Configuration:
# /usr/local/libexec/slapd -VVV     
@(#) $OpenLDAP: slapd 2.4.48 (Sep 10 2019 13:30:19) $
    root@hermite.physics.gla.ac.uk:/var/ports/usr/ports/net/openldap24-server/work/openldap-2.4.48/servers/slapd
Included static overlays:
    constraint
    syncprov
    unique
Included static backends:
    config
    ldif
    relay
# freebsd-version
12.0-RELEASE-p9
This is the most recent currently-packaged version of OpenLDAP on FreeBSD.