OK, I'm really sorry, you're right, I didn't know what a filter was, and by filter, I meant the required attributes. I apologize again for the confusion. Now that it's clear what a filter and the required attributes are, why am I getting different responses to the same LDAP query? If it's a configuration issue, can someone help me find it?
Marco On 05/03/24 16:53, Howard Chu wrote: > 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 >> > >
