openldap-bugs July 2025

openldap-bugs@openldap.org

1 participants
65 discussions

[Issue 10205] New: SSL handshake blocks forever in async mode if server unaccessible
by openldap-its＠openldap.org 23 Sep '25

23 Sep '25

https://bugs.openldap.org/show_bug.cgi?id=10205 Issue ID: 10205 Summary: SSL handshake blocks forever in async mode if server unaccessible Product: OpenLDAP Version: 2.5.17 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: regtube(a)hotmail.com Target Milestone: --- When ldaps:// scheme is used to connect to currently unaccessible server with LDAP_OPT_CONNECT_ASYNC and LDAP_OPT_NETWORK_TIMEOUT options set, it blocks forever on SSL_connect. Here is a trace: ldap_sasl_bind ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP winserv.test.net:636 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying 192.168.56.2:636 ldap_pvt_connect: fd: 3 tm: 30 async: -1 ldap_ndelay_on: 3 attempting to connect: connect errno: 115 ldap_int_poll: fd: 3 tm: 0 ldap_err2string [2024-04-25 15:41:27.112] [error] [:1] bind(): Connecting (X) [2024-04-25 15:41:27.112] [error] [:1] err: -18 ldap_sasl_bind ldap_send_initial_request ldap_int_poll: fd: 3 tm: 0 ldap_is_sock_ready: 3 ldap_ndelay_off: 3 TLS trace: SSL_connect:before SSL initialization TLS trace: SSL_connect:SSLv3/TLS write client hello Looks like it happens because non-blocking mode is cleared from the socket (ldap_ndelay_off) after the first poll for write, and non-blocking mode is never restored before attempt to do tls connect, because of the check that assumes that non-blocking mode has already been set for async mode: if ( !async ) { /* if async, this has already been set */ ber_sockbuf_ctrl( sb, LBER_SB_OPT_SET_NONBLOCK, (void*)1 ); } while in fact it was cleared. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 10361] New: lapo-auditlog: Add olcAuditLogNonBlocking to avoid blocking when logging to named pipes
by openldap-its＠openldap.org 18 Sep '25

18 Sep '25

https://bugs.openldap.org/show_bug.cgi?id=10361 Issue ID: 10361 Summary: lapo-auditlog: Add olcAuditLogNonBlocking to avoid blocking when logging to named pipes Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: a.cudbardb(a)freeradius.org Target Milestone: --- Created attachment 1081 --> https://bugs.openldap.org/attachment.cgi?id=1081&action=edit Patch adding olcAuditlogNonBlocking and a tests for slapo-auditlog The default behaviour of fopen() when called on a named pipe which does not have any reader, is to block, until a reader opens the pipe. This in turn blocks slapo-auditlog when it attempts to write output, and prevents slapd processing requests. Depending on how critical the audit log is, it may be preferable to discard audit log output and continue processing requests if there's no reader available which olcAuditLogNonBlocking: TRUE allows. For clarity the call to fopen() is removed and replaced with open()/fdopen(), allowing us to specify O_* flags as opposed to using fopen() OR open()/fdopen() depending on whether we should block. 0666 are the base permissions used by fopen() when files are created. There were no tests for slapo-auditlog, so a small test suite that tests both the basic behaviour, and blocking/non-blocking writes. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 10360] New: delta-sync can apply old mods
by openldap-its＠openldap.org 17 Sep '25

17 Sep '25

https://bugs.openldap.org/show_bug.cgi?id=10360 Issue ID: 10360 Summary: delta-sync can apply old mods Product: OpenLDAP Version: 2.6.9 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- This might be related to #10358, but not sure. In delta MPR, if an older mod is received on an entry after a newer mod has already been applied by a local user, the older mod is applied and the newer mod is lost. The incoming replication ops are checked for freshness by check_csn_age() but that only checks the incoming cookieCSN against contextCSNs of the same SID. I.e., that check only prevents duplicate mods being replicated multiple times from the same remote provider. If check_csn_age() passes, then syncrepl_message_to_op() is invoked which just applies the mod. It doesn't check the mod or cookieCSN against the entry's current entryCSN. The code in syncrepl_op_mod() performs the checks we need. The code just needs to be pulled into a new function so it can be used in both places. -- You are receiving this mail because: You are on the CC list for the issue.

1 10

[Issue 10358] New: syncrepl can revert an entry's CSN
by openldap-its＠openldap.org 11 Sep '25

11 Sep '25

https://bugs.openldap.org/show_bug.cgi?id=10358 Issue ID: 10358 Summary: syncrepl can revert an entry's CSN Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- Created attachment 1080 --> https://bugs.openldap.org/attachment.cgi?id=1080&action=edit Debug log of an instance of this happening There is a sequence of operations which can force a MPR node to apply changes out of order (essentially reverting an operation). Currently investigating which part of the code that should have prevented this has let it slip. A sample log showing how this happened is attached. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10369] New: Error when trying to modify the olcDbCheckpoint attr: 'olcMultiProvider' cannot have multiple values
by openldap-its＠openldap.org 08 Sep '25

08 Sep '25

https://bugs.openldap.org/show_bug.cgi?id=10369 Issue ID: 10369 Summary: Error when trying to modify the olcDbCheckpoint attr: 'olcMultiProvider' cannot have multiple values Product: OpenLDAP Version: 2.6.10 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: elecharny(a)apache.org Target Milestone: --- When trying to modify the olcDbCheckpoint, I get an error on the olcMultiProvider attribute Here are the logs I get: juil. 17 13:03:32 openldap1 slapd[17224]: conn=1012 op=3 MOD dn="olcDatabase={3}mdb,cn=config" juil. 17 13:03:32 openldap1 slapd[17224]: conn=1012 op=3 MOD attr=olcDbCheckpoint juil. 17 13:03:32 openldap1 slapd[17224]: slap_get_csn: conn=1012 op=3 generated new csn=20250717130332.671384Z#000000#00b#000000 manage=1 juil. 17 13:03:32 openldap1 slapd[17224]: slap_queue_csn: queueing 0x7f02cc104b80 20250717130332.671384Z#000000#00b#000000 juil. 17 13:03:32 openldap1 slapd[17224]: Entry (olcDatabase={3}mdb,cn=config), attribute 'olcMultiProvider' cannot have multiple values juil. 17 13:03:32 openldap1 slapd[17224]: conn=1012 op=3 RESULT tag=103 err=19 qtime=0.000008 etime=0.000185 text=attribute 'olcMultiProvider' cannot > juil. 17 13:03:32 openldap1 slapd[17224]: slap_graduate_commit_csn: removing 0x7f02cc104b80 20250717130332.671384Z#000000#00b#000000 juil. 17 13:03:32 openldap1 slapd[17224]: conn=1012 op=4 UNBIND Here is the content of the olcDatabase={3}mdb,cn=config entry: "olcDatabase={3}mdb,cn=config", { "objectClass":[ "olcDatabaseConfig", "olcMdbConfig" ], "olcDatabase":"{3}mdb", "olcDbDirectory":"/usr/local/openldap/data/worteks/", "olcSuffix":[ "o=service,o=worteks" ], "olcAccess":[ "{0}to * by dn=\"gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth\" read by dn=\"uid=repl,ou=security,o=service,o=worteks\" read by anonymous auth by * none break", "{1}to attrs=userPassword by * none", "{2}to dn.subtree=\"ou=security,o=service,o=worteks\" by * none", "{3}to * by * none" ], "olcAddContentAcl":true, "olcLimits":[ "{0}dn=\"uid=repl,ou=security,o=service,o=worteks\" size=unlimited time=unlimited", "{1}dn=\"gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth\" size=unlimited time=unlimited" ], "olcRootDN":"cn=admin,o=service,o=worteks", "olcRootPW":"secret", "olcSyncrepl":[ "{0}rid=012 provider=ldap://openldap1:10389 binddn=\"uid=repl,ou=security,o=service,o=worteks\" bindmethod=simple credentials=\"secret\" searchbase=\"o=service,o=worteks\" logbase=\"cn=accesslog\" logfilter=\"(&(objectClass=auditWriteObject)(reqResult=0))\" type=refreshAndPersist retry=\"5 +\" timeout=1 syncdata=accesslog", "{1}rid=011 provider=ldap://openldap2:10389 binddn=\"uid=repl,ou=security,o=service,o=worteks\" bindmethod=simple credentials=\"secret\" searchbase=\"o=service,o=worteks\" logbase=\"cn=accesslog\" logfilter=\"(&(objectClass=auditWriteObject)(reqResult=0))\" type=refreshAndPersist retry=\"5 +\" timeout=1 syncdata=accesslog" ], "olcMultiProvider":true, "olcDbCheckpoint":"1024 1", "olcDbNoSync":true, "olcDbIndex":[ "entryUUID eq", "objectClass eq", "entryCSN eq", "uid eq", "mailboxServiceIMAP eq", "mailboxServicePOP eq", "mailPrimaryAddress eq", "mailAlternativeAddress eq", "mailboxHiddenAlias eq" ], "olcDbMaxSize":137438953472 } In this context, I'm trying to modify the incorrect olcDbCheckpoint value from '1024 1' to '0 1', and the olcMultiProvider has only one value. -- You are receiving this mail because: You are on the CC list for the issue.

1 15

[Issue 10254] New: Allow upgrading password hash on bind
by openldap-its＠openldap.org 08 Sep '25

08 Sep '25

https://bugs.openldap.org/show_bug.cgi?id=10254 Issue ID: 10254 Summary: Allow upgrading password hash on bind Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: me(a)floriswesterman.nl Target Milestone: --- Many OpenLDAP installations are likely to contain relatively old password hashes such as SSHA and CRYPT, as modern alternatives such as Argon are only recent additions. Due to the nature of password hashes, it is of course not possible to "unhash" the old values and rehash them with a more modern algorithm. The presence of these old password hashes poses a liability in case of information leaks or hacks. Currently, the only way to upgrade a password hash is to wait for the user to change their password. This can be sped up by expiring passwords and forcing users to change them. However, this can be slow and frequent password rotation is no longer considered a best practice. It would be a very helpful addition to add support for upgrading a password hash on bind. This is implemented in the 389 directory server: https://www.port389.org/docs/389ds/design/pwupgrade-on-bind.html Essentially, when a user binds, the password is checked like normal. In case of a successful bind, the proposed feature would check the hash algorithm used for the password; and in case it is not equal to the current `olcPasswordHash` value, the user-provided password is rehashed using the new algorithm and stored. This way, the old hashes are phased out more quickly, without being a disturbance to users. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 9343] New: Expand ppolicy policy configuration to allow URL filter
by openldap-its＠openldap.org 08 Sep '25

08 Sep '25

https://bugs.openldap.org/show_bug.cgi?id=9343 Issue ID: 9343 Summary: Expand ppolicy policy configuration to allow URL filter Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- Currently, ppolicy only supports a single global default policy, and past that any policies must be manually added to a given user entry if they are supposed to have something other than the default policy. Also, some sites want no default policy, and only a specific subset to have a policy applied to them. For both of these cases, it would be helpful if it were possible to configure a policy to apply to a set of users via a URL similar to the way we handle creating groups of users in dynlist -- You are receiving this mail because: You are on the CC list for the issue.

1 17

[Issue 10304] New: Unable to remove item from directory as part of transaction if it is the last item in that directory
by openldap-its＠openldap.org 08 Sep '25

08 Sep '25

https://bugs.openldap.org/show_bug.cgi?id=10304 Issue ID: 10304 Summary: Unable to remove item from directory as part of transaction if it is the last item in that directory Product: OpenLDAP Version: 2.5.13 Hardware: All OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: sophie.elliott(a)arcticlake.com Target Milestone: --- I am running my ldap server on Debian 11.3, with the mdb backend, using the backported openldap version 2.5.13. I am not 100% certain if this is an issue with OpenLDAP or liblmdb, but I have been running tests in the repo and it looks like the liblmdb tests work fine, so I think it's with OpenLDAP itself. I have been performing a transaction, and deleting entries from a directory during this transaction. This works fine if the item that I am deleting isn't the last entry in its directory, but when it is I get a MDB_NOTFOUND error on the commit transaction call and the delete doesn't go through. Here is an excerpt of the logs when this happens: ``` 67a64334.14e1fc32 0x766ad2a00700 => index_entry_del( 108, "accessGroupID=f23de82f-3a1c-4f88-86bb-bb07f9a0992d,o=[COMPANY],ou=accessGroups,dc=local,dc=[COMPANY],dc=com" ) 67a64334.14e21912 0x766ad2a00700 mdb_idl_delete_keys: 6c [62d34624] 67a64334.14e22812 0x766ad2a00700 <= index_entry_del( 108, "accessGroupID=f23de82f-3a1c-4f88-86bb-bb07f9a0992d,o=[COMPANY],ou=accessGroups,dc=local,dc=[COMPANY],dc=com" ) success 67a64334.14e23a91 0x766ad2a00700 mdb_delete: txn_commit failed: MDB_NOTFOUND: No matching key/data pair found (-30798) ``` Please let me know if I should submit this issue elsewhere, or if this is something that has already been fixed in a more recent version. I'm also happy to provide more details if necessary. Thank you! -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 10371] New: tools don't print useful error codes
by openldap-its＠openldap.org 08 Sep '25

08 Sep '25

https://bugs.openldap.org/show_bug.cgi?id=10371 Issue ID: 10371 Summary: tools don't print useful error codes Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: client tools Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- In tools/common.c, if ldap_result() returns an error, this return value is used directly as an LDAP error code in the subsequent call to tool_perror(). That is incorrect; ldap_result() always returns -1 on errors. The actual return code must be retrieved using ldap_get_option(ld, LDAP_OPT_RESULT_CODE,...). So up till now the tools have never printed the actual error message that's relevant to whatever failure occurred. Other applications appear to have copied this erroneous behavior. E.g., in investigating ITS#10370 I see that curl's code does the same thing. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 10374] New: pcache olcOverlay={0}pcache,olcDatabase={2}sql,cn=config: template index 0 invalid
by openldap-its＠openldap.org 08 Sep '25

08 Sep '25

https://bugs.openldap.org/show_bug.cgi?id=10374 Issue ID: 10374 Summary: pcache olcOverlay={0}pcache,olcDatabase={2}sql,cn=config: template index 0 invalid Product: OpenLDAP Version: 2.6.8 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: bertrand(a)jacquin.bzh Target Milestone: --- Hi, As a follow-up from https://bugs.openldap.org/show_bug.cgi?id=10373, it appears that the configuration I had shared can be converted to olc with slaptest, however does not pass validation be loaded when the daemon start: ``` $ slaptest -f /etc/openldap/slapd.conf -F /etc/openldap/slapd.d $ slaptest -u -F /etc/openldap/slapd.d -d stats -d pcache unrecognized log level "pcache" (deferred) Total # of attribute sets to be cached = 16. Template: query template: (mail=) attributes: * + Template: query template: (objectClass=*) attributes: * + Template: query template: (objectClass=*) attributes: mail Template: query template: (objectClass=) attributes: ou cn givenName sn mail telephoneNumber description jpegPhoto objectClass Template: query template: (objectClass=*) attributes: ou cn givenName sn mail telephoneNumber description jpegPhoto objectClass Template: query template: (&(objectClass=)(&(jpegPhoto=*)(|(mail=)))) attributes: ou cn givenName sn mail telephoneNumber description jpegPhoto objectClass Template: query template: (objectClass=) attributes: ou cn givenName sn mail telephoneNumber jid description jpegPhoto objectClass Template: query template: (objectClass=*) attributes: ou cn givenName sn mail telephoneNumber jid description jpegPhoto objectClass Template: query template: (&(objectClass=)(&(jpegPhoto=*)(|(mail=)))) attributes: ou cn givenName sn mail telephoneNumber jid description jpegPhoto objectClass Template: query template: (jid=) attributes: jid config error processing olcOverlay={0}pcache,olcDatabase={2}sql,cn=config: template index 0 invalid (0->15) slaptest: bad configuration directory! ``` From the following slapd.conf: ``` overlay pcache pcache mdb 65536 16 1024 60 directory /var/lib/openldap-data/pcache pcacheMaxQueries 1024 # No TTR, see https://bugs.openldap.org/show_bug.cgi?id=10373 # Cache DN pcacheAttrset 0 1.1 pcacheTemplate (objectClass=) 0 3600 60 0 pcacheTemplate (objectClass=*) 0 3600 60 0 pcacheTemplate (&(objectClass=)(&(jpegPhoto=*)(|(mail=)))) 0 3600 60 0 pcacheAttrset 1 jid pcacheTemplate (jid=) 1 3600 60 0 pcacheAttrset 2 ou cn givenname sn mail telephonenumber jid description jpegphoto objectClass pcacheTemplate (&(objectClass=)(&(jpegPhoto=*)(|(mail=)))) 2 3600 60 0 pcacheTemplate (objectClass=*) 2 3600 60 0 pcacheTemplate (objectClass=) 2 3600 60 0 pcacheAttrset 3 ou cn givenname sn mail telephonenumber description jpegphoto objectClass pcacheTemplate (&(objectClass=)(&(jpegPhoto=*)(|(mail=)))) 3 3600 60 0 pcacheTemplate (objectClass=*) 3 3600 60 0 pcacheTemplate (objectClass=) 3 3600 60 0 pcacheAttrset 4 mail pcacheTemplate (objectClass=*) 4 3600 60 0 pcacheAttrset 5 * + pcacheTemplate (objectClass=*) 5 3600 60 0 pcacheTemplate (mail=) 5 3600 60 0 ``` The following olc configuration get generated ``` $ cat /etc/openldap/slapd.d/cn=config/olcDatabase={2}sql/olcOverlay={0}pcache/olcDatabase={0}mdb.ldif # AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify. # CRC32 20578f61 dn: olcDatabase={0}mdb objectClass: olcMdbConfig objectClass: olcPcacheDatabase olcDatabase: {0}mdb olcDbDirectory: /var/lib/openldap-data/pcache olcDbNoSync: FALSE olcDbMaxReaders: 0 olcDbMaxSize: 10485760 olcDbMode: 0600 olcDbSearchStack: 16 olcDbMaxEntrySize: 0 olcDbRtxnSize: 10000 structuralObjectClass: olcMdbConfig entryUUID: ff5661e1-1259-4408-89a8-68f3c1b36095 creatorsName: cn=config createTimestamp: 20250724124836Z entryCSN: 20250724124836.628803Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20250724124836Z $ cat /etc/openldap/slapd.d/cn=config/olcDatabase={2}sql/olcOverlay={0}pcache.ldif # AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify. # CRC32 a8cfafe8 dn: olcOverlay={0}pcache objectClass: olcOverlayConfig objectClass: olcPcacheConfig olcOverlay: {0}pcache olcPcache: mdb 65536 16 1024 60 olcPcacheAttrset: 1 jid olcPcacheAttrset: 2 ou cn givenName sn mail telephoneNumber jid description jp egPhoto objectClass olcPcacheAttrset: 3 ou cn givenName sn mail telephoneNumber description jpegPh oto objectClass olcPcacheAttrset: 4 mail olcPcacheAttrset: 5 * + olcPcacheTemplate: "(mail=)" 5 3600 60 0 0 olcPcacheTemplate: "(objectClass=*)" 5 3600 60 0 0 olcPcacheTemplate: "(objectClass=*)" 4 3600 60 0 0 olcPcacheTemplate: "(objectClass=)" 3 3600 60 0 0 olcPcacheTemplate: "(objectClass=*)" 3 3600 60 0 0 olcPcacheTemplate: "(&(objectClass=)(&(jpegPhoto=*)(|(mail=))))" 3 3600 60 0 0 olcPcacheTemplate: "(objectClass=)" 2 3600 60 0 0 olcPcacheTemplate: "(objectClass=*)" 2 3600 60 0 0 olcPcacheTemplate: "(&(objectClass=)(&(jpegPhoto=*)(|(mail=))))" 2 3600 60 0 0 olcPcacheTemplate: "(jid=)" 1 3600 60 0 0 olcPcacheTemplate: "(&(objectClass=)(&(jpegPhoto=*)(|(mail=))))" 0 3600 60 0 0 olcPcacheTemplate: "(objectClass=*)" 0 3600 60 0 0 olcPcacheTemplate: "(objectClass=)" 0 3600 60 0 0 olcPcachePosition: tail olcPcacheMaxQueries: 1024 olcPcachePersist: FALSE olcPcacheValidate: FALSE olcPcacheOffline: FALSE structuralObjectClass: olcPcacheConfig entryUUID: dbee2888-2741-4298-abc3-81ae4bd9433a creatorsName: cn=config createTimestamp: 20250724124836Z entryCSN: 20250724124836.628803Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20250724124836Z ``` Is this a known limitation at the moment ? Cheers, Bertrand -- You are receiving this mail because: You are on the CC list for the issue.

1 4

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs July 2025