openldap-bugs October 2023

openldap-bugs@openldap.org

2 participants
189 discussions

[Issue 10100] New: Non-sequential timestamps being logged on Windows
by openldap-its＠openldap.org 09 Dec '25

09 Dec '25

https://bugs.openldap.org/show_bug.cgi?id=10100 Issue ID: 10100 Summary: Non-sequential timestamps being logged on Windows Product: OpenLDAP Version: 2.6.6 Hardware: x86_64 OS: Windows Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: smckinney(a)symas.com Target Milestone: --- Presents as a dsync during replication. Consumer will log ``` 650af021.2eadd901 0000000000001b40 slap_queue_csn: queueing 0000000002ac1620 20230920131409.992477Z#000000#001#000000 650af021.2eaed239 0000000000001b40 slap_graduate_commit_csn: removing 0000000002ac1620 20230920131409.992477Z#000000#001#000000 650af021.317b2a35 000000000000185c do_syncrep2: rid=102 CSN too old, ignoring 20230920131409.040136Z#000000#001#000000 (uid=slapd-test1-FOO1-6,ou=People,dc=example,dc=com) ``` The entry was not be added. The provider will log messages using non-sequential timestamps. For example, when grepping the CSN from above (in provider log): ``` # This: 650af021.3b3060d9 0000000000001ad8 conn=1001 op=1 syncprov_sendresp: to=002, cookie=rid=102,sid=001,csn=20230920131409.992477Z#000000#001#000000 # and: 650af021.02648749 0000000000001810 slap_get_csn: conn=1003 op=7 generated new csn=20230920131409.040136Z#000000#001#000000 manage=1 ``` -- You are receiving this mail because: You are on the CC list for the issue.

1 8

[Issue 10113] New: make connection debug output more uniform
by openldap-its＠openldap.org 09 Dec '25

09 Dec '25

https://bugs.openldap.org/show_bug.cgi?id=10113 Issue ID: 10113 Summary: make connection debug output more uniform Product: OpenLDAP Version: 2.6.6 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: enhancement Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- Here's what some of the debug output looks like currently: 6529a16e.07884bd6 0x7f7a68dff640 daemon: epoll: listen=8 active_threads=0 tvp=NULL 6529a16e.0788551d 0x7f7a68dff640 daemon: activity on 1 descriptor 6529a16e.07885e63 0x7f7a68dff640 daemon: activity on:6529a16e.07886607 0x7f7a68dff640 6529a16e.07886f93 0x7f7a68dff640 daemon: epoll: listen=7 active_threads=0 tvp=NULL 6529a16e.07887737 0x7f7a68dff640 daemon: epoll: listen=8 active_threads=0 tvp=NULL 6529a16e.0788987f 0x7f7a63fff640 tls_write: want=239 error=Broken pipe 6529a16e.0788a369 0x7f7a63fff640 TLS trace: SSL_accept:SSLv3/TLS write session ticket 6529a16e.0788d027 0x7f7a63fff640 connection_read(12): unable to get TLS client DN, error=49 id=1000 6529a16e.0788e6cc 0x7f7a63fff640 conn=1000 fd=12 TLS established tls_ssf=128 ssf=128 tls_proto=TLSv1.3 tls_cipher=TLS_AES_128_GCM_SHA256 6529a16e.078974a9 0x7f7a68dff640 daemon: activity on 2 descriptors 6529a16e.07898cf1 0x7f7a68dff640 daemon: activity on:6529a16e.07899409 0x7f7a68dff640 12r6529a16e.07899ef3 0x7f7a68dff640 6529a16e.0789a839 0x7f7a68dff640 daemon: read active on 12 6529a16e.0789c1de 0x7f7a68dff640 daemon: epoll: listen=7 active_threads=0 tvp=NULL 6529a16e.0789cd0e 0x7f7a68dff640 daemon: epoll: listen=8 active_threads=0 tvp=NULL 6529a16e.0789d9e0 0x7f7a68dff640 daemon: activity on 1 descriptor 6529a16e.0789e36d 0x7f7a68dff640 daemon: activity on:6529a16e.0789eaca 0x7f7a68dff640 6529a16e.0789f26e 0x7f7a68dff640 daemon: epoll: listen=7 active_threads=0 tvp=NULL 6529a16e.0789fd9d 0x7f7a68dff640 daemon: epoll: listen=8 active_threads=0 tvp=NULL 6529a16e.078a0a70 0x7f7a63fff640 connection_get(12) 6529a16e.078a1ea0 0x7f7a63fff640 connection_get(12): got connid=1000 6529a16e.078a25b8 0x7f7a63fff640 connection_read(12): checking for input on id=1000 6529a16e.078a32d0 0x7f7a63fff640 ber_get_next 6529a16e.078a6a78 0x7f7a63fff640 tls_read: want=5, got=5 6529a16e.078a7d91 0x7f7a63fff640 0000: 30 05 02 01 02 0.... 6529a16e.078aa0c2 0x7f7a63fff640 tls_write: want=24 error=Broken pipe 6529a16e.078aa820 0x7f7a63fff640 ldap_read: want=8 error=Broken pipe 6529a16e.078ab121 0x7f7a63fff640 ber_get_next on fd 12 failed errno=32 (Broken pipe) 6529a16e.078aba67 0x7f7a63fff640 connection_read(12): input error=-2 id=1000, closing. 6529a16e.078ac3ae 0x7f7a63fff640 connection_closing: readying conn=1000 sd=12 for close 6529a16e.078ad0c6 0x7f7a63fff640 connection_close: conn=1000 sd=12 6529a16e.078aed26 0x7f7a63fff640 daemon: removing 12 6529a16e.078b2ffd 0x7f7a68dff640 daemon: activity on 1 descriptor 6529a16e.078b4616 0x7f7a63fff640 conn=1000 fd=12 closed (connection lost) Most operations will be logged with "conn=xxxx fd=yy blah blah" but things like connection_close etc log "blah blah conn=xxxx sd=yy" instead. It would be nice if they all uniformly started with "conn=xxxx fd=yy blah blah" This is a trivial change. Could be a good first-time commit for a new dev. -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 10086] New: test059 does not set up valid cn=config replication
by openldap-its＠openldap.org 09 Dec '25

09 Dec '25

https://bugs.openldap.org/show_bug.cgi?id=10086 Issue ID: 10086 Summary: test059 does not set up valid cn=config replication Product: OpenLDAP Version: 2.6.4 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: test suite Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- For cn=config replication to be valid, the entryUUIDs must match throughout the config database. However, this is not the case when test059 executes. The entryUUID for 'dn: cn=config' differs between the two. Example: quanah@apito1:~/git/quanah/openldap-scratch/tests/testrun$ grep entryUUID: cfcon.d/cn\=config.ldif entryUUID: aea058c4-bf6e-103d-9e18-4582986e9372 quanah@apito1:~/git/quanah/openldap-scratch/tests/testrun$ grep entryUUID: db.1.a/cn\=config\,cn\=consumer.ldif entryUUID: ae9bd858-bf6e-103d-871e-5daccf782d22 -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Bug 9224] New: Add support for PREPARE/2-phase commit
by openldap-its＠openldap.org 08 Dec '25

08 Dec '25

https://bugs.openldap.org/show_bug.cgi?id=9224 Bug ID: 9224 Summary: Add support for PREPARE/2-phase commit Product: LMDB Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- In LMDB, add support for PREPARE/2-phase commits -- You are receiving this mail because: You are on the CC list for the bug.

1 3

[Issue 9584] New: cn=config replication ops/refresh should pause server
by openldap-its＠openldap.org 08 Dec '25

08 Dec '25

https://bugs.openldap.org/show_bug.cgi?id=9584 Issue ID: 9584 Summary: cn=config replication ops/refresh should pause server Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- Looking into this crash: https://git.openldap.org/openldap/openldap/-/jobs/7286 The thread in question is running a plain syncrepl refresh while another thread seems to have done the same. This thread fetched the entryUUID attribute of the 'cn=config' entry as 'a' and in the meantime, that entry has been rewritten, with 'a' presumably cleaned up and returned to the pool, so addressing a->a_nvals[0] is a NULL-dereference now. This might or might not be related to the fix in ITS#8102. -- You are receiving this mail because: You are on the CC list for the issue.

1 19

[Issue 9972] New: SSS needs READ instead of SEARCH access
by openldap-its＠openldap.org 04 Dec '25

04 Dec '25

https://bugs.openldap.org/show_bug.cgi?id=9972 Issue ID: 9972 Summary: SSS needs READ instead of SEARCH access Product: OpenLDAP Version: 2.6.3 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: dpa-openldap(a)aegee.org Target Milestone: --- I have configured an OpenLDAP 2.6 server with dn: olcDatabase=mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: mdb olcAccess: to dn="cn=bodies,dc=aegee,dc=org" by * search # no problem if this is READ olcAccess: to dn.sub="dc=aegee,dc=org" by * read … dn: olcOverlay=sssvlv,olcDatabase={1}mdb,cn=config objectClass:olcOverlayConfig The content of the tree is available anymously by calling ldapsearch -ZZxH ldap://ldap.aegee.org -b "dc=aegee,dc=org" -s sub . When I modify the call to use SSS: ldapsearch -ZxH ldap://ldap.aegee.org -b "dc=aegee,dc=org" -s sub -E sss=ou:2.5.13.15 it also returns results, but ends with ``` # search result search: 93 result: 50 Insufficient access # numResponses: 3 # numEntries: 2 ``` When I modify above: olcAccess: to dn="cn=bodies,dc=aegee,dc=org" by * read then the access is sufficient. There is no entry called "dn:cn=bodies,dc=aegee,dc=org", or rather the entry shall not be returned on searches and `ldapsearch -ZxH ldap://ldap.aegee.org -b "dc=aegee,dc=org" -s sub` does not return it. These work without a problem: ldapsearch -ZxH ldap://ldap.aegee.org -b "cn=bodies,dc=aegee,dc=org" -s one -E sss=ou:2.5.13.15 ldapsearch -ZxH ldap://ldap.aegee.org -b "cn=bodies,dc=aegee,dc=org" -s sub ldapsearch -ZxH ldap://ldap.aegee.org -b "cn=bodies,dc=aegee,dc=org" -s one This produces Insufficient access: ldapsearch -ZxH ldap://ldap.aegee.org -b "cn=bodies,dc=aegee,dc=org" -s sub -E sss=ou:2.5.13.15 That said client-side-sorting does work without a problem, but server-side sorting requires not only SEARCH, but also READ privileges on dn="cn=bodies,dc=aegee,dc=org". I find this is a bug: SSS requires read-acesss to data, which is not supposed to be returned to the client (dn:cn=bodies,dc=aegee,dc=org). For the additional server-side sorting no additional privileges shall be required, compared to returning the results without server-side-sorting. -- You are receiving this mail because: You are on the CC list for the issue.

1 12

[Issue 9909] New: slap* tools leak cn=config entries on shutdown
by openldap-its＠openldap.org 04 Dec '25

04 Dec '25

https://bugs.openldap.org/show_bug.cgi?id=9909 Issue ID: 9909 Summary: slap* tools leak cn=config entries on shutdown 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: --- slap* tools set up their in-memory cn=config structures but cfb->cb_root is never released on shutdown. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 9902] New: Make max index DBs for back-mdb configurable
by openldap-its＠openldap.org 04 Dec '25

04 Dec '25

https://bugs.openldap.org/show_bug.cgi?id=9902 Issue ID: 9902 Summary: Make max index DBs for back-mdb configurable Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- From ITS#9895: Currently there is a hardcoded limit of 128 index DBs in back-mdb. Some sites want more than this (although there's no evidence they actually use more than 128 attributes in all of their applications' search filters). For 2.5/2.6 we can simply double the constant. For 2.7 consider making it configurable. Note that increasing the number increases the size of an LMDB transaction structure, and also increases the time needed to initialize it whenever creating a transaction, so it's a bad idea to just set this to an arbitrarily large number. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 9881] New: Ability to track last authentication for database objects
by openldap-its＠openldap.org 04 Dec '25

04 Dec '25

https://bugs.openldap.org/show_bug.cgi?id=9881 Issue ID: 9881 Summary: Ability to track last authentication for database objects Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- For simple binds, we have the ability to track the last success via the lastbind functionality (pwdLastSuccess attribute). However this doesn't allow one to see when an object that exists in a database last authenticated via SASL. It would be useful to add similar functionality for SASL binds. This can be useful information that allows one to tell if an object is being actively authenticated to (generally, users and system accounts, etc). Obviously if something is directly mapped to an identity that doesn't exist in the underlying DB, that cannot be tracked. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 9829] New: set timeouts in remoteauth overlay
by openldap-its＠openldap.org 04 Dec '25

04 Dec '25

https://bugs.openldap.org/show_bug.cgi?id=9829 Issue ID: 9829 Summary: set timeouts in remoteauth overlay Product: OpenLDAP Version: 2.5.11 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: --- Currently, it seems there is no way to configure timeouts in the remoteauth overlay. For example, if I define a remoteauth_mapping with a file containing a list of hostnames, the first one is checked first. After "remoteauth_retry_count" * "connect_timeout" seconds, (210s on my system), remoteauth test the second server in the list. In some circumstances, it could be nice to set the connect timeout lower (or higher). -- You are receiving this mail because: You are on the CC list for the issue.

1 7

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs October 2023