https://bugs.openldap.org/show_bug.cgi?id=10030
Issue ID: 10030
Summary: Add support for OpenSSL 3.0 to 2.5 stable release
Product: OpenLDAP
Version: 2.5.14
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
As OpenSSL 1.1.1 is being sunset September 2023 we will need to add OpenSSL 3.0
support to the 2.5 series.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10041
Issue ID: 10041
Summary: unnecessary dynlist evaluation
Product: OpenLDAP
Version: 2.5.14
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: david.coutadeur(a)gmail.com
Target Milestone: ---
Created attachment 963
--> https://bugs.openldap.org/attachment.cgi?id=963&action=edit
openldap config + data for showing the dynlist usecase
Evaluation of member of dynamic groups by dynlist can be slow.
However, in some context, the evaluation is not necessary, especially when
searching object that are not dynamic groups.
You can find attached a configuration and data file showing the use case:
- 10000 users
- 100 static groups
- 5000 dynamic groups, with a filter (&(uid=user*)(objectClass=person),
grabbing all users
Example of "normal" slow search ~ 115s:
ldapsearch -x -H 'ldap://localhost:389/' -D
'uid=admin,ou=people,dc=my-organization,dc=com' -w 'secret' -b
'ou=groups,dc=my-organization,dc=com'
'(member=uid=user1,ou=people,dc=my-organization,dc=com)'
Example of abnormal slow search ~ 115s:
ldapsearch -x -H 'ldap://localhost:389/' -D
'uid=admin,ou=people,dc=my-organization,dc=com' -w 'secret' -b
'ou=groups,dc=my-organization,dc=com'
'(&(objectClass=groupOfNames)(member=uid=user1,ou=people,dc=my-organization,dc=com))'
Here, the filter about the objectClass could be evaluated first to avoid
unnecessary search in dynamic groups.
Example of rapid search with DSA IT ~ 1ms:
ldapsearch -x -H 'ldap://localhost:389/' -D
'uid=admin,ou=people,dc=my-organization,dc=com' -w 'secret' -b
'ou=groups,dc=my-organization,dc=com'
'(&(objectClass=groupOfNames)(member=uid=user1,ou=people,dc=my-organization,dc=com))'
-M
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10000
Issue ID: 10000
Summary: Potential memory leak in tests/progs/slapd-watcher.c
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: test suite
Assignee: bugs(a)openldap.org
Reporter: 1061499390(a)qq.com
Target Milestone: ---
Version: Github:master
Potential memory leak in slapd-watcher.c line 517.Calling ldap_search_ext_s()
without calling ldap_msgfree() to free the memory will cause a memory leak.
Doc says "Note that res parameter of ldap_search_ext_s() and
ldap_search_s() should be freed with ldap_msgfree() regardless of return value
of these functions." in
https://www.openldap.org/software/man.cgi?query=ldap_search_ext_s&apropos=0…
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10023
Issue ID: 10023
Summary: Asynchronous connects are broken
Product: OpenLDAP
Version: 2.5.14
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: ipuleston(a)sonicwall.com
Target Milestone: ---
We have a port of OpenLDAP client running in an embedded system, which is using
asynchronous connects to the LDAP server. We have been using OpenLDAP 2.4.40
for a long time, and I just upgraded it to use 2.5.14 (as the current LTS
release). After doing this, async connects to the LDAP server no longer work.
You can see this in the following debug output:
A successful async connect with 2.4.40:
ldap_send_initial_request
ldap_new_connection 1 1 0
ldap_int_open_connection
ldap_connect_to_host: TCP Ian-DC1.sd80.com:389
ldap_pvt_gethostbyname_a: host=Ian-DC1.sd80.com, r=0
ldap_new_socket: 251
ldap_prepare_socket: 251
ldap_connect_to_host: Trying 192.168.168.3:389
ldap_pvt_connect: fd: 251 tm: 10 async: -1
ldap_ndelay_on: 251
attempting to connect:
connect errno: 115
ldap_int_poll: fd: -1 tm: 0
A failed async connect with 2.5.14:
ldap_send_initial_request
ldap_new_connection 1 1 0
ldap_int_open_connection
ldap_connect_to_host: TCP Ian-DC1.sd80.com:389
ldap_pvt_gethostbyname_a: host=Ian-DC1.sd80.com, r=0
ldap_new_socket: 247
ldap_prepare_socket: 247
ldap_connect_to_host: Trying 10.21.61.3:389
ldap_pvt_connect: fd: 247 tm: 10 async: -1
ldap_ndelay_on: 247
attempting to connect:
connect errno: 115
ldap_open_defconn: successful
ldap_send_server_request
Sending Bind Request, len=0x6ca10c1f
ldap_write: want=63 error=Resource temporarily unavailable
Note that in both cases the connect attempt returns errno 115, EINPROGRESS,
meaning that it has not completed. But after that:
● 2.4.40 calls ldap_int_poll (via ldap_send_initial_request ->
ldap_int_check_async_open) to begin the wait for async completion.
● 2.5.14 instead reports a successful connect, and tries to send the bind which
fails since thre socket is not yet connected.
I tracked the problem down to a change made for ITS #8022 "an async connect may
still succeed immediately" in this commit:
https://git.openldap.org/openldap/openldap/-/commit/ae6347bac12bbf843678a83…
That change in ldap_new_connection makes it set lconn_status for an async
connect to LDAP_CONNST_CONNECTED rather than LDAP_CONNST_CONNECTING if
ldap_int_open_connection returns 0. The problem is that
ldap_int_open_connection returns 0 after getting the EINPROGRESS.
ldap_connect_to_host returns -2 for the latter, but ldap_int_open_connection
doesn't check for that, returning 0 for any return code other than -1.
I think that the bug is actually in ldap_int_open_connection rather than in the
above commit. It should probably return -2 when ldap_connect_to_host returns
that.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10011
Issue ID: 10011
Summary: Incompatibilities with stricter C99 compilers
Product: OpenLDAP
Version: 2.6.4
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: build
Assignee: bugs(a)openldap.org
Reporter: sam(a)gentoo.org
Target Milestone: ---
Newer C compilers (>= Clang 16 and likely >= GCC 14) reject some constructs
removed in C99 like implicit function declarations and implicit ints. Some
compilers are also starting to reject obsolete K&R prototypes which were
removed in C23.
I've filed an MR at
https://git.openldap.org/openldap/openldap/-/merge_requests/605 to address the
issues in configure as well as a small number of issues in the codebase itself.
For more information, see LWN.net [0] or LLVM's Discourse [1], the Gentoo wiki
[2],
or the (new) c-std-porting mailing list [3].
[0] https://lwn.net/Articles/913505/
[1]
https://discourse.llvm.org/t/configure-script-breakage-with-the-new-werror-…
[2] https://wiki.gentoo.org/wiki/Modern_C_porting
[3] hosted at lists.linux.dev.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10079
Issue ID: 10079
Summary: Facing syncrepl issue after selecting filter and attrs
Product: OpenLDAP
Version: 2.4.49
Hardware: x86_64
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: ramprasad.sharma(a)orange.com
Target Milestone: ---
I'm facing an issue,
when I'm using replication without filter and attrs, it works fine but when I
try it with filter and attrs , I get nentries=0 and replication dont happen..
what could be the possible issue, I tried many thing..
syncrepl rid=<%= @%>
provider=ldaps://master.<%= @%>h:636/
bindmethod=simple
binddn="cn=replication,dc=di-diod,dc=tech"
credentials=<%= @%>
searchbase="ou=people,dc=di-diod,dc=tech"
filter="(objectClass=posixAccount)"
attrs="cn,uid,x1sshPubKey,x2sshPubKey,uidNumber,gidNumber,homeDirectory,gecos,loginShell,description,sshPublicKey"
scope=sub
schemachecking=on
type=refreshOnly
interval=00:00:00:01
retry="30 5 300 3"
I can use any help on call also..
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10078
Issue ID: 10078
Summary: segfault error 4 in in dynlist-2.5.so.0.1.8
Product: OpenLDAP
Version: 2.5.13
Hardware: All
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: gustav(a)spllg.de
Target Milestone: ---
whenever i execute an ldapsearch, slapd crashes and i find the following lines
in /var/log/syslog
segfault at 0 ip 00007f876bece9c1 sp 00007f876a1fc0c0 error 4 in
dynlist-2.5.so.0.1.8[7f876becb000+6000] likely on CPU 0 (core 0, socket 0)
Code: 48 29 d0 48 89 d7 48 89 c1 31 c0 83 c1 6c c1 e9 03 f3 48 ab 48 8b 84 24
10 02 00 00 4c 89 ef c7 84 24 a0 00 00 00 03 00 00 00 <48> 8b 00 ff 50 78 44 39
73 64 74 09 45 84 e4 0f 85 22 03 00 00 48
Stopping OpenLDAP: slapd.
slapd.service: Deactivated successfully.
the database had been imported from ldap-2.4.57 where ldap runs fine.
is there anything i can do to fix the problem?
--
You are receiving this mail because:
You are on the CC list for the issue.
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(a)openldap.org
Reporter: daniel.walker(a)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.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10069
Issue ID: 10069
Summary: Error when installing openldap from brew on Macos
Catalina
Product: OpenLDAP
Version: 2.6.4
Hardware: x86_64
OS: Mac OS
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: build
Assignee: bugs(a)openldap.org
Reporter: marianogedisman(a)gmail.com
Target Milestone: ---
Hello!
I'm getting this error when installing from Homebrew on MacOS Catalina:
==> ./configure --prefix=/usr/local/Cellar/openldap/2.6.4
--sysconfdir=/usr/loca
n==> make install
Error: inreplace failed
/usr/local/etc/openldap/slapd.conf:
expected replacement of #<Pathname:/usr/local/Cellar/openldap/2.6.4> with
#<Pathname:/usr/local/opt/openldap>
/usr/local/etc/openldap/slapd.ldif:
expected replacement of #<Pathname:/usr/local/Cellar/openldap/2.6.4> with
#<Pathname:/usr/local/opt/openldap>
--
You are receiving this mail because:
You are on the CC list for the issue.