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.