(ITS#8686) modrdn can't find the target dn if it is read directly from hdb backend - openldap-bugs

6 Jul 2017


      Full_Name: Yoshiho Yoshida
Version: 2.4.44
OS: CentOS 6.5
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (210.237.186.4)
This issue only happens with hdb back-end database.
If the target dn is not in the cache memory, then modrdn tries to get it from
hdb using its normalized rdn.
As this result, modrdn can't find the target dn with "No such attribute (16)" or
"No such object (32)" error.
no cache --> dn2id.bdb -- id -->  id2entry.bdb
The problem seems to exist in the buffer size to get id from dn2id.bdb.
Test case uses uid as rdn and its syntax is SYNTAX
1.3.6.1.4.1.1466.115.121.1.15{256} .
Then this normalize is,
  1) Normalization of UTF-8 (NKFC mormalization)
  2) consecutive space characters to a single space
  3) trim the ending space
If the size of original rdn and normalized rdn is as follows, this problem
occurs.
len_rdn is the size of original rdn.
len_norm_rdn is the size of normalized rdn.
((3 + len_norm_rdn) * 3) less than equal to ((3 + len_norm_rdn) + 1 + len_rdn +
1 + 8)
Test case:
1. Test data
$ cat zzz.ldif
dn: dc=zzz
dc: zzz
objectClass: dcObject
objectClass: organization
o: zzz domain
$ cat yyy.ldif
dn: dc=yyy,dc=zzz
o: yyy.zzz domain
objectClass: dcObject
objectClass: organization
dc: yyy
$ cat people.ldif
dn: ou=people,dc=yyy,dc=zzz
ou: people
objectClass: organizationalRole
cn: people
$ cat xxx.ldif
dn: uid=xxx,ou=people,dc=yyy,dc=zzz
sn: xxx
cn: xxx
uid: xxx
objectClass: inetOrgPerson
$
2. Add the above test data into ldap database (hdb)
$ ldapadd -v -x -h 192.168.10.131 -D'uid=zimbra,cn=admins,cn=zimbra' -w password
-f zzz.ldif
ldap_initialize( ldap://192.168.10.131 )
add dc:
        zzz
add objectClass:
        dcObject
        organization
add o:
        zzz domain
adding new entry "dc=zzz"
modify complete
$ ldapadd -v -x -h 192.168.10.131 -D'uid=zimbra,cn=admins,cn=zimbra' -w password
-f yyy.ldif
ldap_initialize( ldap://192.168.10.131 )
add o:
        yyy.zzz domain
add objectClass:
        dcObject
        organization
add dc:
        yyy
adding new entry "dc=yyy,dc=zzz"
modify complete
$ ldapadd -v -x -h 192.168.10.131 -D'uid=zimbra,cn=admins,cn=zimbra' -w password
-f people.ldif
ldap_initialize( ldap://192.168.10.131 )
add ou:
        people
add objectClass:
        organizationalRole
add cn:
        people
adding new entry "ou=people,dc=yyy,dc=zzz"
modify complete
$ ldapadd -v -x -h 192.168.10.131 -D'uid=zimbra,cn=admins,cn=zimbra' -w password
-f xxx.ldif
ldap_initialize( ldap://192.168.10.131 )
add sn:
        xxx
add cn:
        xxx
add uid:
        xxx
add objectClass:
        inetOrgPerson
adding new entry "uid=xxx,ou=people,dc=yyy,dc=zzz"
modify complete
$
o Verify the added dn
$ ldapsearch -LL -x -h 192.168.10.131 -D 'uid=zimbra,cn=admins,cn=zimbra' -w
password uid=xxx
version: 1
dn: uid=xxx,ou=people,dc=yyy,dc=zzz
sn: xxx
cn: xxx
uid: xxx
objectClass: inetOrgPerson
$
3. modify the above dn (rdn)
$ cat modrdn_1.ldif
uid=xxx,ou=people,dc=yyy,dc=zzz
uid=\20a
$
$ ldapmodrdn -v -x -r -h 192.168.10.131 -p 389 -D
'uid=zimbra,cn=admins,cn=zimbra' -w password -f modrdn_1.ldif
ldap_initialize( ldap://192.168.10.131:389 )
Renaming "uid=xxx,ou=people,dc=yyy,dc=zzz"
        new rdn="uid=\20a" (delete old rdn)
Rename Result: Success (0)
$
o Verify the changed rdn
$ ldapsearch -LL -x -h 192.168.10.131 -D 'uid=zimbra,cn=admins,cn=zimbra' -w
password "uid= a"
version: 1
dn: uid=\20a,ou=people,dc=yyy,dc=zzz
sn: xxx
cn: xxx
objectClass: inetOrgPerson
uid:: IGE=
$
o Start the recurrence test
4. Restart the slapd to remove the cache
$ ldap stop
Killing slapd with pid 15740 done.
$
$ tail /var/log/zimbra.log
Jul  7 12:53:46 jpzcserv1 slapd[15740]: conn=1002 fd=18 closed (slapd shutdown)
Jul  7 12:53:46 jpzcserv1 slapd[15740]: conn=1003 fd=20 closed (slapd shutdown)
Jul  7 12:53:46 jpzcserv1 slapd[15740]: conn=1004 fd=22 closed (slapd shutdown)
Jul  7 12:53:46 jpzcserv1 slapd[15740]: conn=1005 fd=24 closed (slapd shutdown)
Jul  7 12:53:46 jpzcserv1 slapd[15740]: slapd shutdown: waiting for 0
operations/tasks to finish
Jul  7 12:53:46 jpzcserv1 slapd[15740]: slapd stopped.
$
$ ldap start
Started slapd: pid 16998
$ 
$ tail /var/log/zimbra.log
Jul  7 12:54:58 jpzcserv1 slapd[16997]: @(#) $OpenLDAP: slapd 2.4.44 (May 30
2017 23:19:56) $#012#011root@jpzcserv1.zimbra.jp:/home/yyoshida/zimbra/work/OpenLDAP_244/openldap-2.4.44/servers/slapd
Jul  7 12:54:58 jpzcserv1 slapd[16998]: slapd starting
$
5. Then try to modify the rdn
$ cat modrdn_2.ldif
uid=\20a,ou=people,dc=yyy,dc=zzz
uid=abc
$
$ ldapmodrdn -v -x -r -h 192.168.10.131 -p 389 -D
'uid=zimbra,cn=admins,cn=zimbra' -w password -f modrdn_2.ldif
ldap_initialize( ldap://192.168.10.131:389 )
Renaming "uid=\20a,ou=people,dc=yyy,dc=zzz"
        new rdn="uid=abc" (delete old rdn)
Rename Result: No such attribute (16)
Additional info: modify/delete: uid: no such attribute
$
Failed with " No such attribute (16)"
6. Then search the target dn to load the entry to cache
$ ldapsearch -LL -x -h 192.168.10.131 -D 'uid=zimbra,cn=admins,cn=zimbra' -w
password "uid= a"
version: 1
dn: uid=\20a,ou=people,dc=yyy,dc=zzz
sn: xxx
cn: xxx
objectClass: inetOrgPerson
uid:: IGE=
$
7. Again modify the same rdn
$ ldapmodrdn -v -x -r -h 192.168.10.131 -p 389 -D
'uid=zimbra,cn=admins,cn=zimbra' -w password -f modrdn_2.ldif
ldap_initialize( ldap://192.168.10.131:389 )
Renaming "uid=\20a,ou=people,dc=yyy,dc=zzz"
        new rdn="uid=abc" (delete old rdn)
Rename Result: Success (0)
$
Now it can be modified successfully.
This problem found when the replica server needed to be restarted and it never
synchronized with the master server
because there are some bad dn data. The master server is also possible to have
this problem if it needs to be restarted.
Workaround)
 dn2id.c
 increase the size of data.ulen in hdb_dn2id()
data.ulen = data.size * 3; 
    d = op->o_tmpalloc( data.size * 3, op->o_tmpmemctx );