Dear openldap-technical, I have encountered an issue with slapo-translucent and I am trying to determine whether it is a problem with my configuration or a bug.
By mistake, I opened a ticket on OpenLDAP ITS, and rightfully, I have been redirected here. https://bugs.openldap.org/show_bug.cgi?id=10184 The problem is as follows: the results from a translucent OpenLDAP server do not return any entry when a single attribute is present in the query filter. This attribute has been previously modified and is present in the local database of the translucent OpenLDAP server. To better explain the issue, I have set up an environment with containers. The repository is as follows: https://github.com/voidloop/openldap-bug To bring up the environment, two commands are needed: % make submodules % make docker-run Three containers will be running: upstream: a simple LDAP server with a couple of users, listening on port 51389/tcp. buggy: the translucent server from upstream with the problematic behavior, listening on port 52389/tcp. compiled: the translucent server from upstream recompiled with the modified code where I suspect there might be an issue, listening on port 53389/tcp. The containers are simple Fedora instances with OpenLDAP. Once the following ldapmodify command is executed: % ldapmodify -x -D cn=buggy,dc=example,dc=com -w password -H ldap://:52389 <<EOF dn: uid=ciccio,ou=people,dc=example,dc=com changetype: modify replace: uidNumber uidNumber: 99 EOF The following occurs: 1) Querying servers without filters: ------------------------------------------------------------------------------- Server "upstream" ------------------------------------------------------------------------------- % ldapsearch -x -H ldap://:51389 -b ou=people,dc=example,dc=com uid=ciccio # extended LDIF # # LDAPv3 # base <ou=people,dc=example,dc=com> with scope subtree # filter: uid=ciccio # requesting: ALL # # ciccio, people, example.com dn: uid=ciccio,ou=people,dc=example,dc=com objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson objectClass: posixAccount uid: ciccio cn: Ciccio Bello sn: Bello uidNumber: 1000 gidNumber: 1000 homeDirectory: /home/ciccio # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 ------------------------------------------------------------------------------- Translucent server "buggy" ------------------------------------------------------------------------------- % ldapsearch -x -H ldap://:52389 -b ou=people,dc=example,dc=com uid=ciccio # extended LDIF # # LDAPv3 # base <ou=people,dc=example,dc=com> with scope subtree # filter: uid=ciccio # requesting: ALL # # ciccio, people, example.com dn: uid=ciccio,ou=people,dc=example,dc=com objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson objectClass: posixAccount uid: ciccio cn: Ciccio Bello sn: Bello uidNumber: 99 gidNumber: 1000 homeDirectory: /home/ciccio # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 ------------------------------------------------------------------------------- Translucent server "compiled" ------------------------------------------------------------------------------- % ldapsearch -x -H ldap://:53389 -b ou=people,dc=example,dc=com uid=ciccio # extended LDIF # # LDAPv3 # base <ou=people,dc=example,dc=com> with scope subtree # filter: uid=ciccio # requesting: ALL # # ciccio, people, example.com dn: uid=ciccio,ou=people,dc=example,dc=com objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson objectClass: posixAccount uid: ciccio cn: Ciccio Bello sn: Bello uidNumber: 99 gidNumber: 1000 homeDirectory: /home/ciccio # search result search: 2 result: 0 Success # numResponses: 2 So far, everything is okay, no anomalous behavior. The issue arises when a filter is introduced. 2) Querying servers with a filter ------------------------------------------------------------------------------- Server "upstream" ------------------------------------------------------------------------------- % ldapsearch -x -H ldap://:51389 -b ou=people,dc=example,dc=com uid=ciccio uidNumber # extended LDIF # # LDAPv3 # base <ou=people,dc=example,dc=com> with scope subtree # filter: uid=ciccio # requesting: uidNumber # # ciccio, people, example.com dn: uid=ciccio,ou=people,dc=example,dc=com uidNumber: 1000 # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 ------------------------------------------------------------------------------- Translucent server "buggy" (!!) ------------------------------------------------------------------------------- % ldapsearch -x -H ldap://:52389 -b ou=people,dc=example,dc=com uid=ciccio uidNumber # extended LDIF # # LDAPv3 # base <ou=people,dc=example,dc=com> with scope subtree # filter: uid=ciccio # requesting: uidNumber # # search result search: 2 result: 0 Success # numResponses: 1 ------------------------------------------------------------------------------- Translucent server "compiled" ------------------------------------------------------------------------------- % ldapsearch -x -H ldap://:53389 -b ou=people,dc=example,dc=com uid=ciccio uidNumber # extended LDIF # # LDAPv3 # base <ou=people,dc=example,dc=com> with scope subtree # filter: uid=ciccio # requesting: uidNumber # # ciccio, people, example.com dn: uid=ciccio,ou=people,dc=example,dc=com uidNumber: 99 # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 Why does this behavior occur? I expect the "buggy" server to return the uidNumber attribute. The version of OpenLDAP in the container is the one installed with the Fedora package manager. Server configurations are available in the Git repository, but for convenience, I am listing them here: upstream: https://github.com/voidloop/openldap-bug/blob/main/upstream/slapd.ldif https://github.com/voidloop/openldap-bug/blob/main/upstream/entries.ldif buggy: https://github.com/voidloop/openldap-bug/blob/main/buggy/slapd.ldif compiled: https://github.com/voidloop/openldap-bug/blob/main/compiled/slapd.ldif The source code modification is as follows: % diff openldap/servers/slapd/overlays/translucent.c translucent.c -u --- openldap/servers/slapd/overlays/translucent.c 2024-02-29 11:30:52.620837844 +0100 +++ translucent.c 2024-02-29 11:14:11.274843929 +0100 @@ -928,16 +928,7 @@ /* send it now */ rs->sr_entry = re; rs->sr_flags |= REP_ENTRY_MUSTBEFREED; - if ( test_f ) { - rc = test_filter( op, rs->sr_entry, tc->orig ); - if ( rc == LDAP_COMPARE_TRUE ) { - rc = SLAP_CB_CONTINUE; - } else { - rc = 0; - } - } else { - rc = SLAP_CB_CONTINUE; - } + rc = SLAP_CB_CONTINUE; } } else if ( le ) { /* Only a local entry: remote was deleted I have also found posts from individuals who have identified the same issue, but either received no response or the response was unsatisfactory: https://openldap.org/lists/openldap-technical/201304/msg00069.html https://www.openldap.org/lists/openldap-bugs/200905/msg00159.html https://www.openldap.org/lists/openldap-technical/201106/msg00036.html Thank you for your attention, and I apologize for the lengthy message. Marco
