[prev in list] [next in list] [prev in thread] [next in thread]
List: openldap-technical
Subject: slapo-translucent bug?
From: "Marco Esposito M." <marco.esposito () gmail ! com>
Date: 2024-03-05 7:56:15
Message-ID: 4d992fc1-50dc-455e-ad46-33021bbde916 () gmail ! com
[Download RAW message or body]
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:
-------------------------------------------------------------------------------
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