[prev in list] [next in list] [prev in thread] [next in thread]
List: openldap-technical
Subject: Re: slapo-translucent bug?
From: Howard Chu <hyc () symas ! com>
Date: 2024-03-05 15:53:47
Message-ID: ef148566-9ffc-376a-4504-db314bceaaae () symas ! com
[Download RAW message or body]
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/
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic