'Re: slapo-translucent bug?'

[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openldap-technical
Subject:    Re: slapo-translucent bug?
From:       "Marco Esposito M." <marco.esposito () gmail ! com>
Date:       2024-03-05 17:12:54
Message-ID: b097e958-63c3-421b-b700-43d478e7db0d () gmail ! com
[Download RAW message or body]

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
> > 
> 
> 


[prev in list] [next in list] [prev in thread] [next in thread]
Configure | About | News | Add a list | Sponsored by KoreLogic