Marco Esposito M. wrote: > 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:
You need to go reread the LDAP RFCs. What you're calling a "filter" is actually an attribute list. All of your searches are using a filter: uid=ciccio. Re-read the slapo-translucent manpage as well. As I said on that ticket - there are no bugs in this code. Your config is wrong because you don't know what a "filter" is. > > ------------------------------------------------------------------------------- > 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 > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
