https://bugs.openldap.org/show_bug.cgi?id=10184
--- Comment #2 from Marco Esposito M. <[email protected]> --- Sure. I find it challenging to explain this issue just with words, I was hoping that someone else had already encountered this problem, sorry. However, to demonstrate this subtle and unexpected behavior of the slapo-translucent module, I have set up an environment with containers using Docker. The repository is the following: https://github.com/voidloop/openldap-bug To run everything, I have prepared two recipes with make: % make submodules % make docker-run Three containers will be launched: - upstream: a simple LDAP server containing a couple of users. It listens on port 51389/tcp. - buggy: the translucent server of upstream with the subtle behavior, listening on port 52389/tcp. - compiled: the translucent server of upstream recompiled with the modified code where I suspect something is wrong, listening on port 53389/tcp. The repository also contains two scripts: % scripts/mod-buggy.sh % scripts/mod-compiled.sh These scripts simply modify a user on both buggy and compiled: dn: uid=ciccio,ou=people,dc=example,dc=com changetype: modify replace: uidNumber uidNumber: 99 Once executed, the following is observed. 1) OK: querying the 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 Up to this point, everything is fine, no abnormal behavior. The issue arises when a filter is introduced. The filter attribute is local and specified in the configuration as: olcTranslucentLocal: uidNumber (In reality, even if not specified, the same behavior occurs). 2) FAIL: querying the 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 uidNumber. The version of OpenLDAP in the container is the one installed with the Fedora package manager. The configurations of the servers are present in the Git repository, but for convenience, I report 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 modification to the source code is this: % 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 Also, while searching for solutions online, I found posts from people who have sensed the same problem, but they never got an answer or the answer was not satisfactory. Here they are: 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 I hope I have been clear. If nothing is clear yet, I will try again. Thank you, and sorry for the long message. Marco -- You are receiving this mail because: You are on the CC list for the issue.
