https://bugs.openldap.org/show_bug.cgi?id=10075
Issue ID: 10075 Summary: back-sql regression between 2.4.40 and 2.4.44 Product: OpenLDAP Version: 2.4.44 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: backends Assignee: bugs@openldap.org Reporter: daniel.walker@ncas.ac.uk Target Milestone: ---
I have just upgraded from CentOS6 to CentOS7 ( I know, not my pick :). On OpenLdap back-sql 2.4.40 on CentOS6, this seems to be honoured:
"Multiple attributeType definitions are allowed for an entry; that is, multiple ldap_attr_mappings rows can refer to the same ldap_oc_mappings row with the same name; the resulting attribute values are honored for multivalued attributes in search filters, in search results, in compare AVAs. However, only rules according to the first instance of that attributeType are followed in add, modify and delete operations. This limitation, under certain circumstances, may be removed in the future." (from https://www.openldap.org/faq/data/cache/978.html )
I was using this feature to get memberAddress attributes from two separate tables in my SQL (internal people and external people)
Upon upgrading to 2.4.44 on CentOS7, the second entry is no longer honoured.
Relevant entries:
MariaDB [ncas_database]> SELECT name,sel_expr,from_tbls,join_where,add_proc,delete_proc,param_order,expect_return,sel_expr_u FROM ldap_attr_mappings WHERE oc_map_id=4 AND name='memberAddress'; +---------------+--------------------------------------+------------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------+----------+-------------+-------------+---------------+------------+ | name | sel_expr | from_tbls | join_where
| add_proc | delete_proc | param_order | expect_return | sel_expr_u | +---------------+--------------------------------------+------------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------+----------+-------------+-------------+---------------+------------+ | memberAddress | CONCAT(emails.address,"@domain.name") | groups,people_groups AS ps,people,emails | groups.id=ps.group_id AND ps.person_id=people.id AND people.id=emails.person_id AND emails.main=1 AND (people.contract_end > NOW() OR people.contract_end IS NULL) | NULL | NULL | 3 | 0 | NULL | | memberAddress | email | groups,external_members | groups.id=external_members.group_id
| NULL | NULL | 3 | 0 | NULL | +---------------+--------------------------------------+------------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------+----------+-------------+-------------+---------------+------------+ 2 rows in set (0.000 sec)
The second one is ignored; no requests to the external_members table show in the logs.
Is this a known bug? I did look through the archives, but I wasn't able to find it.
https://bugs.openldap.org/show_bug.cgi?id=10075
Quanah Gibson-Mount quanah@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED
--- Comment #1 from Quanah Gibson-Mount quanah@openldap.org --- OpenLDAP 2.4 series is historic and not supported. If you can reproduce the issue with a modern supported release of OpenLDAP, feel free to reopen this issue.
I would also note that there are freely available binary packages of OpenLDAP that can be used from reputable sources, such as:
Symas: https://repo.symas.com/
The LTB project: https://ltb-project.org/
I would strongly advise against using the antiquated builds RH provides.
Regards, Quanah
https://bugs.openldap.org/show_bug.cgi?id=10075
Quanah Gibson-Mount quanah@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords|needs_review | Status|RESOLVED |VERIFIED