[Issue 10184] New: slapo-translucent

List overview All Threads
Download

newer

older

[Issue 10187] New: I need to build...

[Issue 10181] New: No support for...

openldap-its＠openldap.org

28 Feb 2024 28 Feb '24

10:11 a.m.

https://bugs.openldap.org/show_bug.cgi?id=10184

Issue ID: 10184 Summary: slapo-translucent Product: OpenLDAP Version: 2.6.3 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs@openldap.org Reporter: marco.esposito@gmail.com Target Milestone: ---

I am currently experiencing an issue with an OpenLDAP instance configured with the slapo-translucent overlay.

After performing an ldapmodify:

# ldapmodify -x -D cn=Manager,dc=example,dc=com -W -H ldap:/// <<EOF dn: uid=user,ou=People,dc=example,dc=com changetype: modify replace: uidNumber uidNumber: 99 EOF

LDAP queries requesting only translucent local attributes do not return results unless both the remote and local attributes are included in the filter. Here is an example illustrating the behavior:

Query with both remote and local attributes in the filter after ldapmodify (works correctly):

# ldapsearch -x -D "cn=Manager,dc=example,dc=com" -W -H ldap:/// -b "ou=People,dc=example,dc=com" "(uid=user)" uid uidNumber # extended LDIF # # LDAPv3 # base <ou=People,dc=example,dc=com> with scope subtree # filter: uid=user # requesting: uid uidNumber #

# user, People, example.com dn: uid=user,ou=People,dc=example,dc=com uidNumber: 99 uid: user

# search result search: 2 result: 0 Success

# numResponses: 2 # numEntries: 1

Query with only local attributes in the filter after ldapmodify (does not return results):

# ldapsearch -x -D "cn=Manager,dc=example,dc=com" -W -H ldap:/// -b "ou=People,dc=example,dc=com" "(uid=user)" uidNumber # extended LDIF # # LDAPv3 # base <ou=People,dc=example,dc=com> with scope subtree # filter: uid=user # requesting: uidNumber #

# search result search: 2 result: 0 Success

# numResponses: 1

While attempting to debug the issue, I believe the problem may be related to the code in lines 928 - 940 of the file overlays/translucent.c:

https://git.openldap.org/openldap/openldap/-/blob/master/servers/slapd/overl...

Specifically, I suspect that the issue may be related to the conditions within the 'if' statement.

I have carefully reviewed the slapd instance configuration and overlay settings, but I have not been able to identify the root cause. Any assistance or advice on resolving this issue would be greatly appreciated.

Thank you for your time and support.

Best regards, Marco

-- You are receiving this mail because: You are on the CC list for the issue.

Show replies by date

openldap-its＠openldap.org

28 Feb 28 Feb

11 a.m.

New subject: [Issue 10184] slapo-translucent

https://bugs.openldap.org/show_bug.cgi?id=10184

--- Comment #1 from Howard Chu hyc@openldap.org --- Nothing in this ticket indicates a bug. Use the openldap-technical mailing list for software usage questions. Provide your actual overlay configuration, nobody can guess what you're doing. This ticket will be closed unless you provide concrete information showing broken behavior.

-- You are receiving this mail because: You are on the CC list for the issue.

openldap-its＠openldap.org

29 Feb 29 Feb

4:13 a.m.

New subject: [Issue 10184] slapo-translucent

https://bugs.openldap.org/show_bug.cgi?id=10184

--- Comment #2 from Marco Esposito M. marco.esposito@gmail.com --- 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 #

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

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

openldap-its＠openldap.org

6:36 a.m.

New subject: [Issue 10184] slapo-translucent

https://bugs.openldap.org/show_bug.cgi?id=10184

--- Comment #3 from Howard Chu hyc@openldap.org --- I pulled your repo and followed your build instructions.

My results with your containers get no errors:

#### viola:~/OD/hobj/clients/tools> ./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 #

# search result search: 2 result: 0 Success

# numResponses: 2 # numEntries: 1 viola:~/OD/hobj/clients/tools> ./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 #

# search result search: 2 result: 0 Success

# numResponses: 2 # numEntries: 1 viola:~/OD/hobj/clients/tools> ./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 #

# search result search: 2 result: 0 Success

# numResponses: 2 # numEntries: 1 viola:~/OD/hobj/clients/tools> ./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 viola:~/OD/hobj/clients/tools> ./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 #

# 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 viola:~/OD/hobj/clients/tools> ./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: 1000

# search result search: 2 result: 0 Success

# numResponses: 2 # numEntries: 1 viola:~/OD/hobj/clients/tools> ####

-- You are receiving this mail because: You are on the CC list for the issue.

openldap-its＠openldap.org

6:44 a.m.

New subject: [Issue 10184] slapo-translucent

https://bugs.openldap.org/show_bug.cgi?id=10184

--- Comment #4 from Marco Esposito M. marco.esposito@gmail.com --- Alright, after pulling up the containers, try running the scripts in the 'scripts' directory. Alternatively, attempt to modify the uidNumber of users (especially 'ciccio') on the 'buggy' and 'compiled' servers and rerun the test. You'll likely observe unusual behavior

-- You are receiving this mail because: You are on the CC list for the issue.

openldap-its＠openldap.org

6:47 a.m.

New subject: [Issue 10184] slapo-translucent

https://bugs.openldap.org/show_bug.cgi?id=10184

--- Comment #5 from Howard Chu hyc@openldap.org --- No bug here. Fix your config. Use the openldap-technical mailing list for software usage help. This ticket is closed.

-- You are receiving this mail because: You are on the CC list for the issue.

openldap-its＠openldap.org

7:03 a.m.

New subject: [Issue 10184] slapo-translucent

https://bugs.openldap.org/show_bug.cgi?id=10184

--- Comment #6 from Marco Esposito M. marco.esposito@gmail.com --- Sorry, but I have the same configuration as you. Please, one last question: can you execute these commands and show me the output?

% ldapmodify -x -D cn=buggy,dc=example,dc=com -w password -H ldap://localhost:52389 <<EOF dn: uid=ciccio,ou=people,dc=example,dc=com changetype: modify replace: uidNumber uidNumber: 444 EOF

I'm sorry if I may seem insistent, and I truly apologize, but I just don't understand, and I really need this slapo-translucent functionality.

Thank you

-- You are receiving this mail because: You are on the CC list for the issue.

openldap-its＠openldap.org

1 Mar 1 Mar

2:20 a.m.

New subject: [Issue 10184] slapo-translucent

https://bugs.openldap.org/show_bug.cgi?id=10184

--- Comment #7 from Ondřej Kuzník ondra@mistotebe.net --- Marco, it is fine to ask for help but as Howard has pointed out already, this (a bug tracker) is not the place to do that. Please subscribe to the openldap-technical mailing list and continue the discussion there.

This is where you can subscribe: https://lists.openldap.org/postorius/lists/openldap-technical.openldap.org/

-- You are receiving this mail because: You are on the CC list for the issue.