openldap-bugs March 2024

openldap-bugs@openldap.org

2 participants
177 discussions

[Issue 10106] New: Add organization to web list of OpenLDAP support providers
by openldap-its＠openldap.org 12 Nov '24

12 Nov '24

https://bugs.openldap.org/show_bug.cgi?id=10106 Issue ID: 10106 Summary: Add organization to web list of OpenLDAP support providers Product: website Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: website Assignee: bugs(a)openldap.org Reporter: sudo(a)migrateq.io Target Milestone: --- Hello! This request is being opened as suggested by Quanah Gibson-Mount. Could you please add Migrateq to your OpenLDAP Support page on https://openldap.org/support Company: Migrateq Inc. Website: https://migrateq.io/support/tech/openldap Migrateq provides migrations, integrations and advanced 24/7/365 technical support for OpenLDAP and most Linux and Open Source Software. Thank you =) Richard -- You are receiving this mail because: You are on the CC list for the issue.

1 11

[Issue 10141] New: 100% CPU consumption with ldap_int_tls_connect
by openldap-its＠openldap.org 12 Nov '24

12 Nov '24

https://bugs.openldap.org/show_bug.cgi?id=10141 Issue ID: 10141 Summary: 100% CPU consumption with ldap_int_tls_connect Product: OpenLDAP Version: 2.6.3 Hardware: Other OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: vivekanand754(a)gmail.com Target Milestone: --- While doing secure ldap connection, i'm seeing that connection is getting stuck in read block in case it is unable to connect active directory sometime: ~ # strace -p 15049 strace: Process 15049 attached read(3, 0x55ef720bda53, 5) = -1 EAGAIN (Resource temporarily unavailable) read(3, 0x55ef720bda53, 5) = -1 EAGAIN (Resource temporarily unavailable) .. .. .. .. After putting some logs, I can see that "ldap_int_tls_start" function of "openldap-2.6.3/libraries/libldap/tls2.c" calls "ldap_int_tls_connect" in while loop. It seems to be blocking call, as it try to connect continuously until it get connected(ti_session_connect returns 0) and thus consumes 100% CPU during that time. Is there any known issue ? -- You are receiving this mail because: You are on the CC list for the issue.

1 17

[Issue 9920] New: MDB_PAGE_FULL with master3 (encryption) because there is no room for the authentication data (MAC)
by openldap-its＠openldap.org 25 Oct '24

25 Oct '24

https://bugs.openldap.org/show_bug.cgi?id=9920 Issue ID: 9920 Summary: MDB_PAGE_FULL with master3 (encryption) because there is no room for the authentication data (MAC) Product: LMDB Version: unspecified Hardware: x86_64 OS: Mac OS Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: info(a)parlepeuple.fr Target Milestone: --- Created attachment 915 --> https://bugs.openldap.org/attachment.cgi?id=915&action=edit proposed patch Hello, on master3, using the encryption at rest feature, I am testing as follow: - on a new named database, i set the encryption function with mdb_env_set_encrypt(env, encfunc, &enckey, 32) - note that I chose to have a size parameter (The size of authentication data in bytes, if any. Set this to zero for unauthenticated encryption mechanisms.) of 32 bytes. - I add 2 entries on the DB, trying to saturate the first page. I chose to add a key of 33 Bytes and a value of 1977 Bytes, so the size of each node is 2010 Bytes (obviously the 2 keys are different). - This passes and the DB has just one leaf_pages, no overflow_pages, no branch_pages, an a depth of 1. - If I add one byte to the values I insert (starting again from a blank DB), then , instead of seeing 2 overflow_pages, I get an error : MDB_PAGE_FULL. - this clearly should not have happened. - Here is some tracing : add to leaf page 2 index 0, data size 48 key size 7 [74657374646200] add to leaf page 3 index 0, data size 1978 key size 33 [000000000000000000000000000000000000000000000000000000000000000000] add to branch page 5 index 0, data size 0 key size 0 [null] add to branch page 5 index 1, data size 0 key size 33 [000000000000000000000000000000000000000000000000000000000000000000] add to leaf page 4 index 0, data size 1978 key size 33 [000000000000000000000000000000000000000000000000000000000000000000] add to leaf page 4 index 1, data size 1978 key size 33 [020202020202020202020202020202020202020202020202020202020202020202] not enough room in page 4, got 1 ptrs upper-lower = 2020 - 2 = 2016 node size = 2020 Looking at the code, I understand that there is a problem at line 9005 : } else if (node_size + data->mv_size > mc->mc_txn->mt_env->me_nodemax) { where me_nodemax is incorrect, as it is not taking into account that some bytes will be needed for the MAC authentication code, which size is in env->me_esumsize. me_nodemax is calculated at line 5349: env->me_nodemax = (((env->me_psize - PAGEHDRSZ ) / MDB_MINKEYS) & -2) - sizeof(indx_t); So I substract me_esumsize with a "- env->me_esumsize" here: env->me_nodemax = (((env->me_psize - PAGEHDRSZ - env->me_esumsize) / MDB_MINKEYS) & -2) - sizeof(indx_t); I also substract it from me_maxfree_1pg in the line above, and in pmax in line 10435. I do not know if my patch is correct, but it solves the issue. Maybe there are other places in the code where the me_esumsize should be substracted from the available size. By example, when calculating the number of overflow pages in OVPAGES, it does not take into account me_esumsize, but I think it is ok, because there is only one MAC for the entire set of OV pages, and there is room for it in the first OV page. See the attached proposed patch. -- You are receiving this mail because: You are on the CC list for the issue.

1 40

[Issue 9982] New: Linker error when building with LDAP_CONNECTIONLESS
by openldap-its＠openldap.org 22 Oct '24

22 Oct '24

https://bugs.openldap.org/show_bug.cgi?id=9982 Issue ID: 9982 Summary: Linker error when building with LDAP_CONNECTIONLESS Product: OpenLDAP Version: 2.6.3 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: invokesus+openldap(a)gmail.com Target Milestone: --- Created attachment 942 --> https://bugs.openldap.org/attachment.cgi?id=942&action=edit Build log I'm encountering the following linker error when building from the master branch, with LDAP_CONNECTIONLESS defined. /nix/store/jbnmj9fljgnfyc1iswnrpfhlkpnnwiii-binutils-2.39/bin/ld: ./.libs/libldap.so: undefined reference to `ber_sockbuf_io_udp' Seems to have been happening since https://git.openldap.org/openldap/openldap/-/commit/4a87d7aad200aaa91cb0cb8…. Attaching the full build log. Also, attaching in the next update, a patch to fix the error. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 9356] New: Add list of peerSIDs to consumer cookie to reduce cross traffic
by openldap-its＠openldap.org 15 Oct '24

15 Oct '24

https://bugs.openldap.org/show_bug.cgi?id=9356 Issue ID: 9356 Summary: Add list of peerSIDs to consumer cookie to reduce cross traffic Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- If we add a list of peersids to the cookie, each consumer can tell the providers who else the consumers talk to and then the provider can omit sending updates to that consumer, originating from those peers There's some special handling needed if a connection dies If a consumer loses one of its peer connections, and after N retries is still not connected, it should send a new cookie to its remaining peers saying "here's my new peer list" with the missing one removed. Likewise, if a retry eventually connects again, it can send a new cookie again Make that peer list reset configurable in the syncrepl config stanza. This can help account for end admin knowledge that some links may be more or less stable than other ones. The idea here is that if one of your other peers can still see the missing peer, they can start routing updates to you again It should abandon all existing persist sessions and send a new sync search with the new cookie to all remaining peers For consumer side, also means adding the sid for a given provider into the syncrepl stanza to save on having to try and discover the peer sid. -- You are receiving this mail because: You are on the CC list for the issue.

1 10

[Bug 9219] New: Streamline tool API for 2.5
by openldap-its＠openldap.org 15 Oct '24

15 Oct '24

https://bugs.openldap.org/show_bug.cgi?id=9219 Bug ID: 9219 Summary: Streamline tool API for 2.5 Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- The current tool API is a mess and needs fixing for 2.5. This affects things like slapacl (The fix for bug#7920 was a kludge to deal with this, needs revisiting). -- You are receiving this mail because: You are on the CC list for the bug.

1 7

[Issue 9813] New: Incompatibility between remoteauth and ppolicy overlays
by openldap-its＠openldap.org 17 Sep '24

17 Sep '24

https://bugs.openldap.org/show_bug.cgi?id=9813 Issue ID: 9813 Summary: Incompatibility between remoteauth and ppolicy overlays Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: thierry.pubellier(a)paris.fr Target Milestone: --- Hi, We are planning to use OpenLDAP as a proxy for some users in our Active Directory servers, using remoteauth overlay. We want this OpenLDAP instance to also implement an account lockout policy, preventing the lockout on our internal Active Directory servers. But there seems to be an incompatibility between remoteauth and ppolicy overlays : remoteauth won't remote authenticate a user if local userPassword attribute exists, while ppolicy overlay needs this attribute. Could there be a configuration parameter in ppolicy to allow lockout checks/modifications (which seemed to be the default behavior of OpenLDAP before ITS#7089) ? I can provide a patch if allowed. Thanks by advance, Best regards, Thierry -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 10147] New: Bind dn is getting malformed inside ldap_sasl_bind function
by openldap-its＠openldap.org 25 Jun '24

25 Jun '24

https://bugs.openldap.org/show_bug.cgi?id=10147 Issue ID: 10147 Summary: Bind dn is getting malformed inside ldap_sasl_bind function Product: OpenLDAP Version: 2.6.3 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: satishkumar1728(a)gmail.com Target Milestone: --- Hi team, We are using open ldap version 2.6 in one of our application processes. We are using ldap_sasl_bind function defined in open ldap api to send bind request to ldap server. We are passing the dn name to the above function and it is parsing the dn name as expected. We have added some print statements inside ldap_sasl_bind function and it is printing the dn string that we passed to the function. Also, ldap_sasl_bind function will accept const char pointer to dn as an argument. So, it cannot modify the dn string inside the function. But somehow the bind dn is getting malformed and we are getting failed bind response from the ldap server (invalid DN). We did some analysis using tcpdump and we found out that the dn string that we passed to the ldap_sasl_bind function and the dn string from the tcpdump are different. We did some code walkthrough of ldap_sasl_bind function and it is observed that it is doing some ber encoding of dn name inside the function. We are suspecting that the encoding is not happening properly. Example dn that we passed to ldap_sasl_bin function: "uid=abc, ou=users, dc=fds, dc=mr" Dn name that was captured in tcpdump at source: "uid=abc, o dc= dc= dc= dc= dc=mr" Is there any specific reason for the bind DN to get malformed like this inside ldap_sasl_bind function. Do you have any observations like this in any scenario. Kindly provide some inputs to resolve this issue. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 10175] New: Secure LDAP is not working on GCC 10.3.0
by openldap-its＠openldap.org 25 Jun '24

25 Jun '24

https://bugs.openldap.org/show_bug.cgi?id=10175 Issue ID: 10175 Summary: Secure LDAP is not working on GCC 10.3.0 Product: OpenLDAP Version: 2.6.3 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: bluesoulprince(a)gmail.com Target Milestone: --- Hi Team, We have recently migrated our C++ application which is using OpenLDAP 2.6 to GCC version 10.3.0. We are observing difference in LDAP behavior. The non-secure version of LDAP is able to return the result in GCC 10.3.0, however when we switch to secure LDAP, it is not able to return with result. There was no compilation / build issue observed while building our application. Our query is, does secure LDAP from OpenLDAP ver 2.6 have any compatibility issues over GCC 10.3.0? If there are any issues identified over this version, how to resolve those? in which version fixes for them are available? Thanks, Vivek -- You are receiving this mail because: You are on the CC list for the issue.

1 9

[Issue 10138] New: Allow generating multiple nested read transactions from a write transaction
by openldap-its＠openldap.org 18 Jun '24

18 Jun '24

https://bugs.openldap.org/show_bug.cgi?id=10138 Issue ID: 10138 Summary: Allow generating multiple nested read transactions from a write transaction Product: LMDB Version: 0.9.30 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: renault.cle(a)gmail.com Target Milestone: --- Hello, I have a feature request. Would it be possible to read a database from the point of view of a non-yet-committed write transaction? What I want to do is to write a lot of entries into a database, use a couple of threads to read those entries (using MDB_NOTLS) to generate a lot of new entries (that will be written to disk and then once the generation is done, drop the read-transaction handles and write (with MDB_APPEND) those new entries from disk into LMDB. This would have been possible if I had committed the first entries, but unfortunately, it is impossible. I need to do this in the same transaction. Have a great day, kero -- You are receiving this mail because: You are on the CC list for the issue.

1 12

← Newer
1
...
10
11
12
13
14
15
16
17
18
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs March 2024