- openldap-bugs - openldap.org

[Issue 8524] cn=config + ditContentRule
by openldap-its＠openldap.org 02 Nov '23

02 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=8524 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|2.7.0 |--- Component|slapd |documentation Severity|development |normal --- Comment #4 from Quanah Gibson-Mount <quanah(a)openldap.org> --- Need to document how to correctly include this type of configuration as a part of an additional schema include. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8498] slapadd complains about missing attrs
by openldap-its＠openldap.org 02 Nov '23

02 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=8498 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|quanah(a)openldap.org |hyc(a)openldap.org Target Milestone|--- |2.7.0 --- Comment #4 from Quanah Gibson-Mount <quanah(a)openldap.org> --- Specific to using the null base, where these attributes won't exist. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8498] slapadd complains about missing attrs
by openldap-its＠openldap.org 02 Nov '23

02 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=8498 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|2.7.0 |--- Severity|normal |enhancement -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8491] slapdelete test needed
by openldap-its＠openldap.org 02 Nov '23

02 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=8491 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|normal |enhancement --- Comment #3 from Quanah Gibson-Mount <quanah(a)openldap.org> --- requires slapdelete exist first -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8182] setspec matching fails unexpectedly
by openldap-its＠openldap.org 02 Nov '23

02 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=8182 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |VERIFIED -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8182] setspec matching fails unexpectedly
by openldap-its＠openldap.org 02 Nov '23

02 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=8182 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |SUSPENDED --- Comment #3 from Quanah Gibson-Mount <quanah(a)openldap.org> --- patches welcome, has usable workaound -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8182] setspec matching fails unexpectedly
by openldap-its＠openldap.org 02 Nov '23

02 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=8182 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|2.7.0 |--- -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8180] back-sock should not return sucess in case of error
by openldap-its＠openldap.org 02 Nov '23

02 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=8180 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|bugs(a)openldap.org |hyc(a)openldap.org -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8178] back-sock: Timeout to avoid locking
by openldap-its＠openldap.org 02 Nov '23

02 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=8178 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|normal |enhancement -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 10121] New: cldap is not work in 2.6.0
by openldap-its＠openldap.org 02 Nov '23

02 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=10121 Issue ID: 10121 Summary: cldap is not work in 2.6.0 Product: OpenLDAP Version: 2.6.0 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: client tools Assignee: bugs(a)openldap.org Reporter: 1010881517(a)qq.com Target Milestone: --- I can't use ldapsearch to query cldap:/// on 2.6.0, but it works fine on 2.4.0. Do you have any instructions on cldap configuration?ldap and ldapi are normal. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 7981] Feature request: Crypt scheme in pwdPolicy
by openldap-its＠openldap.org 02 Nov '23

02 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=7981 --- Comment #3 from Ondřej Kuzník <ondra(a)mistotebe.net> --- Rather than extending the pwdPolicy objectclass, maybe the new mechanism added in ITS#9343 could be used to override the default scheme if desided? -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 10111] New: dynlist crashes when using member+memberOf@groupOfNames
by openldap-its＠openldap.org 30 Oct '23

30 Oct '23

https://bugs.openldap.org/show_bug.cgi?id=10111 Issue ID: 10111 Summary: dynlist crashes when using member+memberOf@groupOfNames Product: OpenLDAP Version: 2.6.6 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: uberthoth(a)gmail.com Target Milestone: --- slapd crashes if queried for the memberof field if dynlist has this config (which is directly from the manpage for slapo-dynlist): olcDynListAttrSet: groupOfURLs memberURL member+memberOf@groupOfNames There is an example repo with a docker-compose.yml to replicate this issue here: https://github.com/joshuacox/openldap-overlay-dynlist This may be a duplicate of this https://bugs.openldap.org/show_bug.cgi?id=10091 though I did not see a seg fault. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10072] New: Querying for transaction memory use
by openldap-its＠openldap.org 28 Oct '23

28 Oct '23

https://bugs.openldap.org/show_bug.cgi?id=10072 Issue ID: 10072 Summary: Querying for transaction memory use Product: LMDB Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: tagwerk19.openldap(a)innerjoin.org Target Milestone: --- It would be useful to have a way to ask liblmdb how much "dirty memory" a transaction is using, up to that point. The goal is to be able to bundle writes into fewer transactions, making best use of available memory and reducing total disc writes. It is possible for an application to count the number of writes but this has only a loose relation to the *actual* number of dirty pages flagged. The target would be to write data up until the dirty memory gets to a threshold and then commit. I see that there's a: txn->mt_dirty_room and wonder if MDB_IDL_UM_MAX - txn->mt_dirty_room would give a count of that an "aware" application could make use of (an exact count? or maybe a usable and sufficient indication?) The need for this has been sharpened with the use of systemd service files that cap the memory allowed for a process, for example: MemoryHigh=512M If the process reaches this limit and continues to write data, the system uses swap. See: https://invent.kde.org/frameworks/baloo/-/merge_requests/148 Thank you for providing and supporting LMDB -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 10122] New: Deletes are not replicated
by openldap-its＠openldap.org 26 Oct '23

26 Oct '23

https://bugs.openldap.org/show_bug.cgi?id=10122 Issue ID: 10122 Summary: Deletes are not replicated Product: OpenLDAP Version: 2.4.46 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: kinouchi-kazuhito(a)jsdnet.co.jp Target Milestone: --- Thank you for your help. I am doing replication using syncrepl rehreshOnly mode. All of a sudden, entry deletions are no longer reflected to the consumer. Looking at the logs, nonpresent_callback is no longer printed in the consumer's logs. Further parsing the logs shows that after the last nonpresent_callback, the provider and consumer are updating the same attribute on the same entry. How should I recover? -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 9959] New: Expose the lloadd connection endpoints in cn=monitor for identification
by openldap-its＠openldap.org 25 Oct '23

25 Oct '23

https://bugs.openldap.org/show_bug.cgi?id=9959 Issue ID: 9959 Summary: Expose the lloadd connection endpoints in cn=monitor for identification Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: lloadd Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- ITS#9600 introduces a way to operate on lloadd connections, however it is impossible to identify which socket this actually corresponds to. While we're at it, might also expose the current bound identity there. -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 10085] New: test029 can't pass with SLAPD_USE_SASL is set
by openldap-its＠openldap.org 25 Oct '23

25 Oct '23

https://bugs.openldap.org/show_bug.cgi?id=10085 Issue ID: 10085 Summary: test029 can't pass with SLAPD_USE_SASL is set 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: ondra(a)mistotebe.net Target Milestone: --- Running make test with SLAPD_USE_SASL set will fail test029. There is even a comment there that we can't support that functionality as-is when SASL binds are configured. We should probably remove that part of the test or skip it unconditionally for now. -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 10045] New: back-config operations abandoned while waiting in slap_pause_server() aren't committed to ldif
by openldap-its＠openldap.org 24 Oct '23

24 Oct '23

https://bugs.openldap.org/show_bug.cgi?id=10045 Issue ID: 10045 Summary: back-config operations abandoned while waiting in slap_pause_server() aren't committed to ldif 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_pause_server() can take an unbounded time to process and it is possible the operation is abandoned in the meantime (e.g. the connection is lost and the loss is still noticed at this point). However the processing still goes ahead and passed onto back-ldif - where it is discarded as abandoned already so we can end up with an inconsistent view of our persistent configuration. Checking op->o_abandon again after slap_pause_server() finishes might be enough. -- You are receiving this mail because: You are on the CC list for the issue.

2 13

[Issue 10095] New: Race condition causing corruption of mutexes when closing the database
by openldap-its＠openldap.org 23 Oct '23

23 Oct '23

https://bugs.openldap.org/show_bug.cgi?id=10095 Issue ID: 10095 Summary: Race condition causing corruption of mutexes when closing the database Product: LMDB Version: 0.9.30 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: peter(a)peterzhu.ca Target Milestone: --- We're running into a race condition across multiple processes causing the corruption of mutexes when a process closes the database caused by the fix for https://bugs.openldap.org/show_bug.cgi?id=9278 (commit https://git.openldap.org/openldap/openldap/-/commit/f683ffdc81d0edb20437cb7…). Here's the interleaving of two processes (p0 and p1) that can cause this situation. p0: Opens connection to database using mdb_env_create and mdb_env_open. ...some things happen in between... p0: Begins closing the database using mdb_env_close: p0: Calls mdb_env_close0: p0: Acquires write lock on the file lock using mdb_env_excl_lock. p0: Calls pthread_mutex_destroy on the mutexes. SWITCH TO p1 p1: Begins opening the database using mdb_env_create. Then calls mdb_env_open, in mdb_env_open: p1: Calls mdb_env_setup_locks: p1: Calls mdb_env_excl_lock, but it's unable to acquire a write file lock due to p0 holding the write file lock. It waits on acquiring a read file lock. SWITCH TO p0 p0: Calls close on the file descriptor which releases the write lock. SWITCH TO p1 p1: Acquires the read file lock. p1: Does NOT call pthread_mutex_init since it did not acquire a write file lock. ...some things happen in between... p1: Try to lock the mutex using pthread_mutex_lock. This call fails with a EINVAL due to locking a destroyed mutex. I'm not sure how to actually solve this problem. We're currently mitigating this problem by reverting the commit linked above (so no mutexes get destroyed). -- You are receiving this mail because: You are on the CC list for the issue.

1 13

[Issue 7226] olcAuditlogFile should be single valued, but accepts multiple values (additional values ignored)
by openldap-its＠openldap.org 23 Oct '23

23 Oct '23

https://bugs.openldap.org/show_bug.cgi?id=7226 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|CONFIRMED |RESOLVED Resolution|--- |TEST --- Comment #18 from Quanah Gibson-Mount <quanah(a)openldap.org> --- • 242d1e6d by Ondřej Kuzník at 2023-08-21T12:19:16+01:00 ITS#7226 Make olcAuditlogFile SINGLE-VALUE -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9278] New: liblmdb: robust mutexes should not be unmapped
by openldap-its＠openldap.org 23 Oct '23

23 Oct '23

https://bugs.openldap.org/show_bug.cgi?id=9278 Issue ID: 9278 Summary: liblmdb: robust mutexes should not be unmapped Product: LMDB Version: unspecified Hardware: All OS: FreeBSD Status: UNCONFIRMED Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: delphij(a)freebsd.org Target Milestone: --- Created attachment 736 --> https://bugs.openldap.org/attachment.cgi?id=736&action=edit A possible workaround We recently noticed that lmdb would have the memory region containing the robust mutex unmapped on mdb_env_close0(): munmap((void *)env->me_txns, (env->me_maxreaders-1)*sizeof(MDB_reader)+sizeof(MDB_txninfo)); Note that if this is the last unmap for a robust mutex, the FreeBSD implementation would garbage-collect the mutex, making it no longer visible to other processes. As the result, a second instance of the attached test.c (from https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=244493 with minor changes) would trigger the assertion at mdb_txn_begin() because the acquisition of the mutex would return 22 (EINVAL), because the mutex appeared to be a robust mutex, but was invalid. The attached lmdb.diff is a possible workaround for this (it would skip unmapping when setting up the robust mutex for the first time). -- You are receiving this mail because: You are on the CC list for the issue.

1 20

[Issue 10077] New: Integer overflow in util-int.c
by openldap-its＠openldap.org 23 Oct '23

23 Oct '23

https://bugs.openldap.org/show_bug.cgi?id=10077 Issue ID: 10077 Summary: Integer overflow in util-int.c Product: OpenLDAP Version: 2.6.3 Hardware: All OS: Windows Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: michal.pura(a)gmail.com Target Milestone: --- Created attachment 971 --> https://bugs.openldap.org/attachment.cgi?id=971&action=edit the fix proposal for ldap_pvt_gettimensec() function Hello, I found the issue with contextCNS generating process which cause that its format is invalid (minus sign in nanoseconds filed). Example: "generated new csn=20230630080704.-489933Z#000000#000#000000" The bug can introduce the minus sign in the contextCSN what could have an impact in replication process, backup restoring etc. Everywhere when the format of contextCSN is checked before processing it. According to the source code and reference documents the contextCSN nanoseconds filed should have the value from range: 000000-999999. https://www.openldap.org/faq/data/cache/1145.html The problem is in the function ldap_pvt_gettimensec() in util-int.c file. For example in line: count.QuadPart += (10 * BILLION); The value of (10 * BILLION) will be treated as 32-bit value by compilator and will cause the integer overflow. Then the random value is added to count.QuadPart what in some specific cases can produce the negative value which is returned from the function. At the end the value is passed to the function ldap_pvt_csnstr() so the contextCSN is wrongly generated (with minus sign). There is missing 'LL' qualifier, code should looks like this: count.QuadPart += (10LL * BILLION); I also suggest to change the type of _ldap_pvt_gt_offset variable from int to long long. In attachment you will find fix proposal as there are more places in the function where changes are required. -- You are receiving this mail because: You are on the CC list for the issue.

1 9

[Issue 10115] New: Delisting Savoir-faire Linux from support page
by openldap-its＠openldap.org 23 Oct '23

23 Oct '23

https://bugs.openldap.org/show_bug.cgi?id=10115 Issue ID: 10115 Summary: Delisting Savoir-faire Linux from support page Product: website Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: website Assignee: bugs(a)openldap.org Reporter: support(a)savoirfairelinux.com Target Milestone: --- Hello, I am the Vice-President, IT Infrastructure at Savoir-faire Linux and I am writing you to remove our company from the support page on your website because we no longer offer OpenLDAP consulting. -- Hussein Abdallah Vice-president Infrastructures Free Software Consultant & Trainer Email: support(a)savoirfairelinux.com savoirfairelinux.com | Montréal, Québec Jami: habdallah Tél.: +1 514 276 5468 ext. 148 -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 8485] [PATCH] Adding support for encrypted server private keys
by openldap-its＠openldap.org 23 Oct '23

23 Oct '23

https://bugs.openldap.org/show_bug.cgi?id=8485 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |VERIFIED -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8485] [PATCH] Adding support for encrypted server private keys
by openldap-its＠openldap.org 23 Oct '23

23 Oct '23

https://bugs.openldap.org/show_bug.cgi?id=8485 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|2.7.0 |--- Resolution|--- |SUSPENDED Status|UNCONFIRMED |RESOLVED --- Comment #14 from Quanah Gibson-Mount <quanah(a)openldap.org> --- A patch along the lines on comment#12 welcome. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8197] slapo-constraint and delold=0
by openldap-its＠openldap.org 23 Oct '23

23 Oct '23

https://bugs.openldap.org/show_bug.cgi?id=8197 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FEEDBACK Status|UNCONFIRMED |RESOLVED Target Milestone|2.7.0 |--- --- Comment #3 from Quanah Gibson-Mount <quanah(a)openldap.org> --- Need information on what constraint(s) have been implemented that trigger the issue. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9714] New: Use xorshift in libldap/dnssrv.c
by openldap-its＠openldap.org 23 Oct '23

23 Oct '23

https://bugs.openldap.org/show_bug.cgi?id=9714 Issue ID: 9714 Summary: Use xorshift in libldap/dnssrv.c Product: OpenLDAP Version: unspecified 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 discussed in https://git.openldap.org/openldap/openldap/-/merge_requests/417 we may want to shift to using xorshift in libldap/dnssrv.c in a future release. -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 8196] PRNG from ITS#7027 (shuffling DNS SRV records) is poorly seeded
by openldap-its＠openldap.org 23 Oct '23

23 Oct '23

https://bugs.openldap.org/show_bug.cgi?id=8196 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |TEST Status|UNCONFIRMED |RESOLVED Assignee|bugs(a)openldap.org |ondra(a)mistotebe.net --- Comment #2 from Quanah Gibson-Mount <quanah(a)openldap.org> --- commit 1220282dd5f941829e999d612eeb226e532b55d7 Author: Ondřej Kuzník <ondra(a)mistotebe.net> Date: Fri Sep 16 14:49:11 2022 +0100 ITS#8196/ITS#9714 Switch to xorshift -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8149] nssov loginStatus doesn't play well with replication
by openldap-its＠openldap.org 23 Oct '23

23 Oct '23

https://bugs.openldap.org/show_bug.cgi?id=8149 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords|replication | -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 7981] Feature request: Crypt scheme in pwdPolicy
by openldap-its＠openldap.org 23 Oct '23

23 Oct '23

https://bugs.openldap.org/show_bug.cgi?id=7981 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|bugs(a)openldap.org |ondra(a)mistotebe.net -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 7777] Filtering on modifyTimestamp is slower with index
by openldap-its＠openldap.org 23 Oct '23

23 Oct '23

https://bugs.openldap.org/show_bug.cgi?id=7777 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |VERIFIED -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 7777] Filtering on modifyTimestamp is slower with index
by openldap-its＠openldap.org 23 Oct '23

23 Oct '23

https://bugs.openldap.org/show_bug.cgi?id=7777 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |SUSPENDED Target Milestone|2.7.0 |--- --- Comment #4 from Quanah Gibson-Mount <quanah(a)openldap.org> --- patches welcome generally don't index timestamps. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 10114] New: Crash in mdb_copy with stale transactions(?)
by openldap-its＠openldap.org 23 Oct '23

23 Oct '23

https://bugs.openldap.org/show_bug.cgi?id=10114 Issue ID: 10114 Summary: Crash in mdb_copy with stale transactions(?) Product: LMDB Version: 0.9.30 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: zack+ldapbugs(a)owlfolio.org Target Milestone: --- I have a LMDB database which is damaged in some way, I'm not sure exactly how, but the application that created it (KDE baloo_file) crashes on startup while trying to read it, with a backtrace pointing inside liblmdb... #0 __memcpy_avx_unaligned_erms () at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:837 #1 0x00007fbf1fa110b6 in mdb_page_touch (mc=mc@entry=0x7ffe8dc1adf0) at mdb.c:2502 #2 0x00007fbf1fa12c9c in mdb_cursor_touch (mc=mc@entry=0x7ffe8dc1adf0) at mdb.c:6563 #3 0x00007fbf1fa16228 in mdb_cursor_put (mc=mc@entry=0x7ffe8dc1adf0, key=key@entry=0x7ffe8dc1b1e0, data=data@entry=0x7ffe8dc1b1f0, flags=<optimized out>, flags@entry=0) at mdb.c:6697 #4 0x00007fbf1fa18d51 in mdb_put (txn=0x55986d167a70, dbi=<optimized out>, key=0x7ffe8dc1b1e0, data=0x7ffe8dc1b1f0, flags=0) at mdb.c:9076 #5 0x00007fbf1fcec44b in Baloo::PostingDB::put (this=this@entry=0x7ffe8dc1b2d0, term=..., list=...) at /usr/src/debug/kde-frameworks/baloo-5.110.0/baloo-5.110.0/src/engine/postingdb.cpp:66 If I try to mdb_dump the database (with nothing else trying to access it) I get mdb_dump: index: MDB_BAD_TXN: Transaction must abort, has a child, or is invalid That sounds like the sort of thing that ought to be cleared by mdb_copy -c, but instead that command also crashes inside __memcpy_avx_unaligned_erms. Backtrace: #0 __memcpy_avx_unaligned_erms () at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:839 #1 0x0000555555557e67 in mdb_env_cwalk (my=my@entry=0x7fffffffdbc0, pg=pg@entry=0x7fffffffd988, flags=0) at mdb.c:9264 #2 0x0000555555557fdf in mdb_env_cwalk (my=my@entry=0x7fffffffdbc0, pg=pg@entry=0x7fffffffdb90, flags=flags@entry=0) at mdb.c:9306 #3 0x0000555555558523 in mdb_env_copyfd1 (env=0x55555556a2a0, fd=<optimized out>) at mdb.c:9469 #4 0x00005555555588c9 in mdb_env_copy2 (env=0x55555556a2a0, path=<optimized out>, flags=flags@entry=1) at mdb.c:9623 #5 0x0000555555558ea6 in main (argc=3, argv=0x7fffffffe008) at mdb_copy.c:74 I tried to poke at the offending data structure a little but I didn't immediately see what was wrong... (gdb) frame 1 #1 0x0000555555557e67 in mdb_env_cwalk (my=my@entry=0x7fffffffdbc0, pg=pg@entry=0x7fffffffd988, flags=0) at mdb.c:9264 9264 mdb_page_copy(leaf, mp, my->mc_env->me_psize); (gdb) p mp $1 = (MDB_page *) 0x7fc008d32000 (gdb) p *mp $2 = {mp_p = {p_pgno = 0x0606060606060606, p_next = 0x0606060606060606}, mp_pad = 1542, mp_flags = 1542, mp_pb = {pb = {pb_lower = 1542, pb_upper = 18832}, pb_pages = 1234175494}, mp_ptrs = 0x7fc008d32010} ... except that those values for p_pgno and p_next don't look terribly plausible to me. The database file is, unfortunately, much too large to attach here (2.3G uncompressed, 383M compressed with xz -17) and also it's, well, a full-text index of everything I have on my computer, so I'd be hesitant to attach it even if it fit. I can make it available for private download if that would be helpful. I'm also happy to do other experiments. I realize that crashes caused by database corruption can be very difficult to avoid but I hope there might be some kind of easy defensive measure to take in this particular case which could at least allow the application to fail cleanly rather than crashing. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

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

23 Oct '23

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 1

[Issue 10120] New: slapd crashes when changing ARGON2 olcRootPW via ldapmodify
by openldap-its＠openldap.org 23 Oct '23

23 Oct '23

https://bugs.openldap.org/show_bug.cgi?id=10120 Issue ID: 10120 Summary: slapd crashes when changing ARGON2 olcRootPW via ldapmodify Product: OpenLDAP Version: 2.6.5 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: aimass(a)yabarana.com Target Milestone: --- slapd dies when executing LDIF remotely with ldapmodify: This is the command we are running: ldapadd -H ldap://:xxx -x -D xxx -w xxx -f foo.ldif (we are using ldapadd as a convenience because the LDIF file creates and modifies entries) This fragment of foo.ldif causes slapd to die: dn: olcDatabase={0}config,cn=config changetype: modify replace: olcRootPW olcRootPW: {ARGON2}$argon2id$v=19$m=65536,t=128,p=2$******** The last few lines of debug indicate this: 2023-10-23 15:49:36 653679f0.32572d8b 0xffff45945b10 mdb_idl_insert_keys: 56 [f8bb395f] 2023-10-23 15:49:36 653679f0.325f95ba 0xffff45945b10 send_ldap_result: err=0 matched="" text="" 2023-10-23 15:49:36 653679f0.3266665b 0xffff46249b10 connection_get(13) 2023-10-23 15:49:36 653679f0.3266bebc 0xffff46249b10 conn=1010 op=2 do_modify: dn (olcDatabase={0}config,cn=config) 2023-10-23 15:49:36 653679f0.3266c8a9 0xffff46249b10 => ldap_bv2dn(olcDatabase={0}config,cn=config,0) 2023-10-23 15:49:36 653679f0.3266d026 0xffff46249b10 <= ldap_bv2dn(olcDatabase={0}config,cn=config)=0 2023-10-23 15:49:36 653679f0.3266e35b 0xffff46249b10 => ldap_dn2bv(272) 2023-10-23 15:49:36 653679f0.32671cf9 0xffff46249b10 <= ldap_dn2bv(olcDatabase={0}config,cn=config)=0 2023-10-23 15:49:36 653679f0.326723a5 0xffff46249b10 => ldap_dn2bv(272) 2023-10-23 15:49:36 653679f0.32672904 0xffff46249b10 <= ldap_dn2bv(olcDatabase={0}config,cn=config)=0 2023-10-23 15:49:36 653679f0.32672e63 0xffff46249b10 conn=1010 op=2 modifications: 2023-10-23 15:49:36 653679f0.326803c4 0xffff46249b10 replace: olcRootPW 2023-10-23 15:49:36 653679f0.32681a3a 0xffff46249b10 one value, length 384 2023-10-23 15:49:36 Assertion failed: pool->ltp_pause == PAUSED (tpool.c: ldap_pvt_thread_pool_resume: 1319) -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 10119] New: log function do NOT work.
by openldap-its＠openldap.org 22 Oct '23

22 Oct '23

https://bugs.openldap.org/show_bug.cgi?id=10119 Issue ID: 10119 Summary: log function do NOT work. Product: OpenLDAP Version: 2.5.13 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: 142857uk(a)gmail.com Target Milestone: --- The logging function of this version of `slapd` seems not working at all. The configuration of `slapd` is as follow : ``` dn: cn=config objectClass: olcGlobal cn: config olcArgsFile: /var/run/slapd/slapd.args olcLogFile: /tmp/slapd.log olcLogLevel: -1 olcPidFile: /var/run/slapd/slapd.pid olcToolThreads: 1 ``` I set `olcLogLevel` to -1 to enable logging everything. Other values to `olcLogLevel` like 256, 4 were already tested, not working. So stop shitting about this direction. I use `tail` to monitor the content of `/tmp/slapd.log`, nothing! I also checked the permission of `openldap` user on `/tmp/slapd.log`, and it does have the right to write to it. So, shut the fuck up about this direction. Am I like a newbee? My question is, why can't a soooooooo simple function like logging work? Did you guys bother testing it at all before you release your fucking software? I try to be civilization, but you bitches just don't deserve it. Sorry to say that but unfortunately it's a fact. -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 10118] New: slapcat terminates with "double free or corruption (out)" message
by openldap-its＠openldap.org 21 Oct '23

21 Oct '23

https://bugs.openldap.org/show_bug.cgi?id=10118 Issue ID: 10118 Summary: slapcat terminates with "double free or corruption (out)" message Product: OpenLDAP Version: 2.5.13 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: client tools Assignee: bugs(a)openldap.org Reporter: dma_k(a)mail.ru Target Milestone: --- The issue started to appear after upgrading slapd from v2.4.57 to v2.5.13 (Debian bullseye → bookworm). $ slapcat -s cn=config ... double free or corruption (out) Aborted (core dumped) Coredump: #0 0x00007faf0a009d3c n/a (libc.so.6 + 0x8ad3c) #1 0x00007faf09fbaf32 raise (libc.so.6 + 0x3bf32) #2 0x00007faf09fa5472 abort (libc.so.6 + 0x26472) #3 0x00007faf09ffe340 n/a (libc.so.6 + 0x7f340) #4 0x00007faf0a0136ba n/a (libc.so.6 + 0x946ba) #5 0x00007faf0a015720 n/a (libc.so.6 + 0x96720) #6 0x00007faf0a017d9f __libc_free (libc.so.6 + 0x98d9f) #7 0x00005608e5287216 slap_tool_init (slapcat + 0xba216) #8 0x00005608e52864a1 slapcat (slapcat + 0xb94a1) #9 0x00005608e51edc73 main (slapcat + 0x20c73) #10 0x00007faf09fa61ca n/a (libc.so.6 + 0x271ca) #11 0x00007faf09fa6285 __libc_start_main (libc.so.6 + 0x27285) #12 0x00005608e51ef061 _start (slapcat + 0x22061) -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 9936] New: slapd attempting free on address which was not malloced
by openldap-its＠openldap.org 20 Oct '23

20 Oct '23

https://bugs.openldap.org/show_bug.cgi?id=9936 Issue ID: 9936 Summary: slapd attempting free on address which was not malloced 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: kimjuhi96(a)snu.ac.kr Target Milestone: --- I get invalid free running this on the latest openldap from git, built with CFLAGS="-fsanitize=address" using clang 15. Seems this is similar to https://bugs.openldap.org/show_bug.cgi?id=9912. ./servers/slapd/slapd -T c -s1 -s1 Stopped reason: SIGABRT __GI_raise (sig=sig@entry=0x6) at ../sysdeps/unix/sysv/linux/raise.c:50 50 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory. gdb-peda$ bt #0 __GI_raise (sig=sig@entry=0x6) at ../sysdeps/unix/sysv/linux/raise.c:50 #1 0x00007ffff78ca859 in __GI_abort () at abort.c:79 #2 0x00005555556eb04f in __sanitizer::Abort () at /home/juhee/project/foxfuzz/llvm-project/compiler-rt/lib/sanitizer_common/sanitizer_posix_libcdep.cpp:143 #3 0x00005555556e8aac in __sanitizer::Die () at /home/juhee/project/foxfuzz/llvm-project/compiler-rt/lib/sanitizer_common/sanitizer_termination.cpp:58 #4 0x00005555556c5dda in __asan::ScopedInErrorReport::~ScopedInErrorReport (this=0x7fffffffbe7e, __in_chrg=<optimized out>) at /home/juhee/project/foxfuzz/llvm-project/compiler-rt/lib/asan/asan_report.cpp:192 #5 0x00005555556c72b8 in __asan::ReportFreeNotMalloced (addr=<optimized out>, free_stack=0x7fffffffca90) at /home/juhee/project/foxfuzz/llvm-project/compiler-rt/lib/asan/asan_report.cpp:199 #6 0x00005555556c02ab in __interceptor_free (ptr=0x7fffffffe359) at /home/juhee/project/foxfuzz/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:53 #7 0x0000555555d3efe2 in ber_memfree_x () #8 0x0000555555847d33 in ch_free () #9 0x0000555555a31178 in slap_tool_init () #10 0x0000555555a2e54d in slapcat () #11 0x000055555570901f in main () #12 0x00007ffff78cc083 in __libc_start_main (main=0x555555706ef0 <main>, argc=0x5, argv=0x7fffffffdfc8, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffdfb8) at ../csu/libc-start.c:308 #13 0x000055555561011e in _start () at /home/juhee/project/foxfuzz/llvm-project/compiler-rt/lib/sanitizer_common/sanitizer_internal_defs.h:397 gdb-peda$ -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 10116] Use-After-Free (CWE-416)
by openldap-its＠openldap.org 19 Oct '23

19 Oct '23

1 0

[Issue 9888] New: When using cn=config replication, schema updates can corrupt the index database(s)
by openldap-its＠openldap.org 19 Oct '23

19 Oct '23

https://bugs.openldap.org/show_bug.cgi?id=9888 Issue ID: 9888 Summary: When using cn=config replication, schema updates can corrupt the index database(s) 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: --- Today I pushed a schema update out to the config node that holds schema that is replicated to the providers and consumers. Post schema update, 2/11 servers crashed in the mdb online indexing function. I fixed this by slapcat the db and slapadd the db. This is important because it was later revealed that on the 9/11 servers that did not crash or have their database reloaded, ldapsearch would return the wrong attribute names for some attribute:value pairs in the database, which caused mayhem in downstream systems and caused replication issues between the nodes. The 2 nodes that were reloaded immediately after the schema change had the only "good" copies of the database left. To give an example, say an entry was something like: dn: uid=joe,ou=people,dc=example,dc=com uid: joe sn: smith cn: joe smith givenName: joe After the change, the broken servers could return something like: dn: uid=joe,ou=people,dc=example,dc=com uid: joe posixGroup: smith cn: joe smith givenName joe It's not clear how deeply this bug ran in the database. It for sure affected 2 attributes used by the person objectClass. Both of the "replacement" attributes were not valid attributes for the person objectClasses in use. Maybe related to the changes in ITS#9858? -- You are receiving this mail because: You are on the CC list for the issue.

1 19

[Issue 7649] Feature request: numSubordinates attribute
by openldap-its＠openldap.org 12 Oct '23

12 Oct '23

https://bugs.openldap.org/show_bug.cgi?id=7649 --- Comment #5 from Quanah Gibson-Mount <quanah(a)openldap.org> --- https://datatracker.ietf.org/doc/html/draft-boreham-numsubordinates-01 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 7441] cn=config filters ignore {number}
by openldap-its＠openldap.org 12 Oct '23

12 Oct '23

https://bugs.openldap.org/show_bug.cgi?id=7441 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|bugs(a)openldap.org |ondra(a)mistotebe.net -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 7422] olcExtraAttrs doesn't work with ACIs
by openldap-its＠openldap.org 12 Oct '23

12 Oct '23

https://bugs.openldap.org/show_bug.cgi?id=7422 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |VERIFIED -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 7422] olcExtraAttrs doesn't work with ACIs
by openldap-its＠openldap.org 12 Oct '23

12 Oct '23

https://bugs.openldap.org/show_bug.cgi?id=7422 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|2.7.0 |--- Status|UNCONFIRMED |RESOLVED Resolution|--- |SUSPENDED --- Comment #3 from Quanah Gibson-Mount <quanah(a)openldap.org> --- patches still welcome -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 7420] Possible to bypass overlay unique and constraint
by openldap-its＠openldap.org 12 Oct '23

12 Oct '23

https://bugs.openldap.org/show_bug.cgi?id=7420 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|bugs(a)openldap.org |hyc(a)openldap.org -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 7392] ACL a_dn.a_self is skipped in case of "acl_mask: to all values ..."
by openldap-its＠openldap.org 12 Oct '23

12 Oct '23

https://bugs.openldap.org/show_bug.cgi?id=7392 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|bugs(a)openldap.org |hyc(a)openldap.org -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 7347] Exclusive bit masks for: ACL_WADD, ACL_WDEL, and ACL_WRITE
by openldap-its＠openldap.org 12 Oct '23

12 Oct '23

https://bugs.openldap.org/show_bug.cgi?id=7347 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|bugs(a)openldap.org |hyc(a)openldap.org -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 7345] New Feature : Add Connection Information in Access Log Entries
by openldap-its＠openldap.org 12 Oct '23

12 Oct '23

https://bugs.openldap.org/show_bug.cgi?id=7345 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |VERIFIED -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 7345] New Feature : Add Connection Information in Access Log Entries
by openldap-its＠openldap.org 12 Oct '23

12 Oct '23

https://bugs.openldap.org/show_bug.cgi?id=7345 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords|has_patch, IPR_OK | Target Milestone|2.7.0 |--- Resolution|--- |WONTFIX Status|UNCONFIRMED |RESOLVED --- Comment #4 from Quanah Gibson-Mount <quanah(a)openldap.org> --- Better to consume this information from the operational logs at stat level -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 7249] slapd segfault with memberof overlay on frontend db
by openldap-its＠openldap.org 12 Oct '23

12 Oct '23

https://bugs.openldap.org/show_bug.cgi?id=7249 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |VERIFIED -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 7249] slapd segfault with memberof overlay on frontend db
by openldap-its＠openldap.org 12 Oct '23

12 Oct '23

https://bugs.openldap.org/show_bug.cgi?id=7249 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |WONTFIX Target Milestone|2.7.0 |--- Status|IN_PROGRESS |RESOLVED --- Comment #17 from Quanah Gibson-Mount <quanah(a)openldap.org> --- memberof is deprecated, any remaining issues will not be fixed. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 7091] Limit ppolicy_forward_updates
by openldap-its＠openldap.org 12 Oct '23

12 Oct '23

https://bugs.openldap.org/show_bug.cgi?id=7091 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |VERIFIED -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 7091] Limit ppolicy_forward_updates
by openldap-its＠openldap.org 12 Oct '23

12 Oct '23

https://bugs.openldap.org/show_bug.cgi?id=7091 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |WONTFIX Target Milestone|2.7.0 |--- Status|UNCONFIRMED |RESOLVED --- Comment #2 from Quanah Gibson-Mount <quanah(a)openldap.org> --- This would result in broken policies -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 7047] slapd crash on bad indexed translucent
by openldap-its＠openldap.org 12 Oct '23

12 Oct '23

https://bugs.openldap.org/show_bug.cgi?id=7047 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|bugs(a)openldap.org |quanah(a)openldap.org -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 7046] OpenLDAP logs nothing at info priority, excessive at debug priority
by openldap-its＠openldap.org 12 Oct '23

12 Oct '23

https://bugs.openldap.org/show_bug.cgi?id=7046 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |VERIFIED -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 7046] OpenLDAP logs nothing at info priority, excessive at debug priority
by openldap-its＠openldap.org 12 Oct '23

12 Oct '23

https://bugs.openldap.org/show_bug.cgi?id=7046 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |WONTFIX Status|UNCONFIRMED |RESOLVED Target Milestone|2.7.0 |--- --- Comment #2 from Quanah Gibson-Mount <quanah(a)openldap.org> --- better solution is to use local logging introduced with openldap 2.6 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 7008] paged results against ldap-proxy errors with 'cookie is invalid'
by openldap-its＠openldap.org 12 Oct '23

12 Oct '23

https://bugs.openldap.org/show_bug.cgi?id=7008 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|SUSPENDED |WONTFIX --- Comment #17 from Quanah Gibson-Mount <quanah(a)openldap.org> --- See alternative solutions in comment #11 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 7008] paged results against ldap-proxy errors with 'cookie is invalid'
by openldap-its＠openldap.org 12 Oct '23

12 Oct '23

https://bugs.openldap.org/show_bug.cgi?id=7008 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |VERIFIED -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 7008] paged results against ldap-proxy errors with 'cookie is invalid'
by openldap-its＠openldap.org 12 Oct '23

12 Oct '23

1 0

[Issue 10112] New: We are working with the client that comes with openldap and cannot connect to TLS/SSL ldaps
by openldap-its＠openldap.org 12 Oct '23

12 Oct '23

https://bugs.openldap.org/show_bug.cgi?id=10112 Issue ID: 10112 Summary: We are working with the client that comes with openldap and cannot connect to TLS/SSL ldaps Product: OpenLDAP Version: 2.6.6 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: 228844797(a)qq.com Target Milestone: --- Created attachment 985 --> https://bugs.openldap.org/attachment.cgi?id=985&action=edit slapd config Hello developers, Can you help me see how to solve this problem We are working with the client that comes with openldap and cannot connect to TLS/SSL ldaps,But I was able to access it using ldap:389 The server configuration information is as follows: Linux System version：Ubuntu 22.04.3 LTS OpenLDAP version：2.6.6 openssl version：OpenSSL 3.0.2 15 Mar 2022 (Library: OpenSSL 3.0.2 15 Mar 2022) The slapd.ldif certificate is configured as follows: olcTLSCACertificateFile: /usr/local/openldap-2.6.6/cert/demoCA/newcerts/cacert.pem olcTLSCertificateFile: /usr/local/openldap-2.6.6/cert/demoCA/newcerts/slapd01-server.pem olcTLSCertificateKeyFile: /usr/local/openldap-2.6.6/cert/demoCA/private/slapd01-server-key.pem The server startup information is as follows: slapd -4 -F /usr/local/openldap-2.6.6/etc/openldap/slapd.d -h ldap:/// ldaps:/// ldapi:/// Configure the ldap.conf certificate on the client as follows: TLS_CACERT /usr/local/openldap-2.6.6/cert/demoCA/newcerts/ ####################################################################################################### Server local test failed: ldapwhoami -H ldaps://slapd.zxactions.com -d 1 The failure information is as follows: root@openldap-1:/usr/local/openldap-2.6.6/etc/openldap# ldapwhoami -H ldaps://slapd.zxactions.com -d 1 ldap_url_parse_ext(ldaps://slapd.zxactions.com) ldap_create ldap_url_parse_ext(ldaps://slapd.zxactions.com:636/??base) ldap_pvt_sasl_getmech ldap_search put_filter: "(objectclass=*)" put_filter: simple put_simple_filter: "objectclass=*" ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP slapd.zxactions.com:636 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying 192.168.174.128:636 ldap_pvt_connect: fd: 3 tm: -1 async: 0 attempting to connect: connect success TLS trace: SSL_connect:before SSL initialization TLS trace: SSL_connect:SSLv3/TLS write client hello TLS trace: SSL3 alert read:fatal:handshake failure TLS trace: SSL_connect:error in error TLS: can't connect: error:0A000410:SSL routines::sslv3 alert handshake failure. ldap_err2string ldap_sasl_interactive_bind: Can't contact LDAP server (-1) additional info: error:0A000410:SSL routines::sslv3 alert handshake failure ####################################################################################################### Failed to use the openssl tool: openssl s_client -connect slapd.zxactions.com:636 -debug The failure information is as follows: root@openldap-1:/usr/local/openldap-2.6.6/etc/openldap# openssl s_client -connect slapd.zxactions.com:636 -debug CONNECTED(00000003) write to 0x556ccbdb5c40 [0x556ccbdc5b30] (321 bytes => 321 (0x141)) 0000 - 16 03 01 01 3c 01 00 01-38 03 03 1a eb eb eb ad ....<...8....... 0010 - 52 f0 12 36 b2 cd ad 9c-6f c9 de 67 54 13 e3 47 R..6....o..gT..G 0020 - 23 ac 44 5c d9 51 2f d4-a5 0b cf 20 e6 f9 c1 6c #.D\.Q/.... ...l 0030 - e5 ce 18 9c ea f1 d6 67-a2 1f 71 3c 78 d4 c6 fb .......g..q<x... 0040 - 25 23 98 bd 38 90 1f 8c-13 94 b1 00 00 3e 13 02 %#..8........>.. 0050 - 13 03 13 01 c0 2c c0 30-00 9f cc a9 cc a8 cc aa .....,.0........ 0060 - c0 2b c0 2f 00 9e c0 24-c0 28 00 6b c0 23 c0 27 .+./...$.(.k.#.' 0070 - 00 67 c0 0a c0 14 00 39-c0 09 c0 13 00 33 00 9d .g.....9.....3.. 0080 - 00 9c 00 3d 00 3c 00 35-00 2f 00 ff 01 00 00 b1 ...=.<.5./...... 0090 - 00 00 00 18 00 16 00 00-13 73 6c 61 70 64 2e 7a .........slapd.z 00a0 - 78 61 63 74 69 6f 6e 73-2e 63 6f 6d 00 0b 00 04 xactions.com.... 00b0 - 03 00 01 02 00 0a 00 16-00 14 00 1d 00 17 00 1e ................ 00c0 - 00 19 00 18 01 00 01 01-01 02 01 03 01 04 00 23 ...............# 00d0 - 00 00 00 16 00 00 00 17-00 00 00 0d 00 2a 00 28 .............*.( 00e0 - 04 03 05 03 06 03 08 07-08 08 08 09 08 0a 08 0b ................ 00f0 - 08 04 08 05 08 06 04 01-05 01 06 01 03 03 03 01 ................ 0100 - 03 02 04 02 05 02 06 02-00 2b 00 05 04 03 04 03 .........+...... 0110 - 03 00 2d 00 02 01 01 00-33 00 26 00 24 00 1d 00 ..-.....3.&.$... 0120 - 20 92 75 81 9c 09 28 95-68 b4 eb b1 9e 2c d5 9b .u...(.h....,.. 0130 - e3 99 13 36 68 87 b5 72-4d d6 3e 60 0f 47 50 db ...6h..rM.>`.GP. 0140 - 15 . read from 0x556ccbdb5c40 [0x556ccbdbc913] (5 bytes => 5 (0x5)) 0000 - 15 03 03 00 02 ..... read from 0x556ccbdb5c40 [0x556ccbdbc918] (2 bytes => 2 (0x2)) 0000 - 02 28 .( 800B77514E7F0000:error:0A000410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure:../ssl/record/rec_layer_s3.c:1584:SSL alert number 40 --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 7 bytes and written 321 bytes Verification: OK --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated Early data was not sent Verify return code: 0 (ok) --- read from 0x556ccbdb5c40 [0x556ccbd0d650] (8192 bytes => 0) -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 6912] support for case sensitive SASL usernames
by openldap-its＠openldap.org 09 Oct '23

09 Oct '23

https://bugs.openldap.org/show_bug.cgi?id=6912 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |VERIFIED -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 6912] support for case sensitive SASL usernames
by openldap-its＠openldap.org 09 Oct '23

09 Oct '23

1 0

[Issue 6871] Feature Request: slapo-lastbind authTimeStamp attribute replicated in MMR deploy
by openldap-its＠openldap.org 09 Oct '23

09 Oct '23

https://bugs.openldap.org/show_bug.cgi?id=6871 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |VERIFIED -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 6871] Feature Request: slapo-lastbind authTimeStamp attribute replicated in MMR deploy
by openldap-its＠openldap.org 09 Oct '23

09 Oct '23

https://bugs.openldap.org/show_bug.cgi?id=6871 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #2 from Quanah Gibson-Mount <quanah(a)openldap.org> --- This is already built into OpenLDAP 2.6 with the pwdLastSuccess attribute which supports chaining and replicates a consistent value to all nodes. *** This issue has been marked as a duplicate of issue 9863 *** -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9863] New: lastbind configuration fails to honor chaining configuration
by openldap-its＠openldap.org 09 Oct '23

09 Oct '23

https://bugs.openldap.org/show_bug.cgi?id=9863 Issue ID: 9863 Summary: lastbind configuration fails to honor chaining configuration Product: OpenLDAP Version: 2.6.2 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: --- In an environment where consumers are configured to chain writes up to the providers, lastbind configuration fails to honor this which is generally what one would expect. This causes mismatches between the providers and consumers in regards to the database state. Additionally it introduces random serverIDs into the database. In my case, the providers have serverIDs 10, 20, 30 configured but the consumer is generating serverID 1 for the entryCSN. Expectation: consumer does not generate *any* entryCSN value and instead forwards the write op to the provider. Log from consumer: slap_get_csn: conn=1069 op=0 generated new csn=20220610180137.644625Z#000000#001#000000 manage=1 -- You are receiving this mail because: You are on the CC list for the issue.

1 12

[Issue 6868] When used in conjunction with the translucent overlay, the rwm overlay filters out auxiliary objectclasses
by openldap-its＠openldap.org 09 Oct '23

09 Oct '23

https://bugs.openldap.org/show_bug.cgi?id=6868 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |VERIFIED --- Comment #4 from Quanah Gibson-Mount <quanah(a)openldap.org> --- Is this still relevant since Samba4 uses its own ldap server? -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 6868] When used in conjunction with the translucent overlay, the rwm overlay filters out auxiliary objectclasses
by openldap-its＠openldap.org 09 Oct '23

09 Oct '23

1 0

[Issue 6477] Clarify ambiguous TLS/SSL Errors in libldap/tls2c.
by openldap-its＠openldap.org 09 Oct '23

09 Oct '23

https://bugs.openldap.org/show_bug.cgi?id=6477 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |VERIFIED -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 6477] Clarify ambiguous TLS/SSL Errors in libldap/tls2c.
by openldap-its＠openldap.org 09 Oct '23

09 Oct '23

https://bugs.openldap.org/show_bug.cgi?id=6477 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #11 from Quanah Gibson-Mount <quanah(a)openldap.org> --- *** This issue has been marked as a duplicate of issue 9157 *** -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9157] return additional error code information when OPT_X_TLS_NEWCTX fails
by openldap-its＠openldap.org 09 Oct '23

09 Oct '23

https://bugs.openldap.org/show_bug.cgi?id=9157 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bseklecki(a)noc.cfi.pgh.pa.us --- Comment #6 from Quanah Gibson-Mount <quanah(a)openldap.org> --- *** Issue 6477 has been marked as a duplicate of this issue. *** -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 6440] slapcat could write info about how it was run in form of LDIF comments
by openldap-its＠openldap.org 09 Oct '23

09 Oct '23

https://bugs.openldap.org/show_bug.cgi?id=6440 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |VERIFIED -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 6440] slapcat could write info about how it was run in form of LDIF comments
by openldap-its＠openldap.org 09 Oct '23

09 Oct '23

https://bugs.openldap.org/show_bug.cgi?id=6440 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |SUSPENDED Target Milestone|2.7.0 |--- Status|UNCONFIRMED |RESOLVED --- Comment #2 from Quanah Gibson-Mount <quanah(a)openldap.org> --- patches welcome -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 6299] Support for RFC 4529 in slapo-allowed
by openldap-its＠openldap.org 09 Oct '23

09 Oct '23

https://bugs.openldap.org/show_bug.cgi?id=6299 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |VERIFIED -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 6299] Support for RFC 4529 in slapo-allowed
by openldap-its＠openldap.org 09 Oct '23

09 Oct '23

https://bugs.openldap.org/show_bug.cgi?id=6299 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |SUSPENDED Status|UNCONFIRMED |RESOLVED Target Milestone|2.7.0 |--- --- Comment #5 from Quanah Gibson-Mount <quanah(a)openldap.org> --- does not provide reliable answer to the query, needs a solid use case and workable solution. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 5919] URI syntaxe (ldap:///dc=my%2cdc=domaine)
by openldap-its＠openldap.org 09 Oct '23

09 Oct '23

https://bugs.openldap.org/show_bug.cgi?id=5919 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |VERIFIED -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 5919] URI syntaxe (ldap:///dc=my%2cdc=domaine)
by openldap-its＠openldap.org 09 Oct '23

09 Oct '23

https://bugs.openldap.org/show_bug.cgi?id=5919 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |SUSPENDED Status|UNCONFIRMED |RESOLVED Target Milestone|2.7.0 |--- Keywords|has_patch | --- Comment #32 from Quanah Gibson-Mount <quanah(a)openldap.org> --- has serious security issues, no real use case. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 5714] [feature request] operational attrs defined via configuration
by openldap-its＠openldap.org 09 Oct '23

09 Oct '23

https://bugs.openldap.org/show_bug.cgi?id=5714 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |VERIFIED Target Milestone|2.7.0 |--- -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 5714] [feature request] operational attrs defined via configuration
by openldap-its＠openldap.org 09 Oct '23

09 Oct '23

https://bugs.openldap.org/show_bug.cgi?id=5714 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #2 from Quanah Gibson-Mount <quanah(a)openldap.org> --- dsaschema contrib module handles this already. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 5601] set-acl failure under back-ldap+rwm
by openldap-its＠openldap.org 09 Oct '23

09 Oct '23

https://bugs.openldap.org/show_bug.cgi?id=5601 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |VERIFIED -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 5601] set-acl failure under back-ldap+rwm
by openldap-its＠openldap.org 09 Oct '23

09 Oct '23

https://bugs.openldap.org/show_bug.cgi?id=5601 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX Target Milestone|2.7.0 |--- --- Comment #7 from Quanah Gibson-Mount <quanah(a)openldap.org> --- has workaround -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 5628] dereferencing user with translucent overlay
by openldap-its＠openldap.org 09 Oct '23

09 Oct '23

https://bugs.openldap.org/show_bug.cgi?id=5628 --- Comment #9 from Quanah Gibson-Mount <quanah(a)openldap.org> --- requires adding entry_get to translucent overlay -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 5628] dereferencing user with translucent overlay
by openldap-its＠openldap.org 09 Oct '23

09 Oct '23

https://bugs.openldap.org/show_bug.cgi?id=5628 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|normal |enhancement -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 5399] LDAP Syntax 1.3.6.1.4.1.1466.115.121.1.58 (Substring Assertion) not listed in subschema subentry
by openldap-its＠openldap.org 09 Oct '23

09 Oct '23

https://bugs.openldap.org/show_bug.cgi?id=5399 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |VERIFIED -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 5399] LDAP Syntax 1.3.6.1.4.1.1466.115.121.1.58 (Substring Assertion) not listed in subschema subentry
by openldap-its＠openldap.org 09 Oct '23

09 Oct '23

https://bugs.openldap.org/show_bug.cgi?id=5399 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |SUSPENDED Target Milestone|2.7.0 |--- Status|UNCONFIRMED |RESOLVED --- Comment #9 from Quanah Gibson-Mount <quanah(a)openldap.org> --- suspending due to lack of use case. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 5356] Catching index ownership errors
by openldap-its＠openldap.org 09 Oct '23

09 Oct '23

https://bugs.openldap.org/show_bug.cgi?id=5356 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |VERIFIED -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 5356] Catching index ownership errors
by openldap-its＠openldap.org 09 Oct '23

09 Oct '23

https://bugs.openldap.org/show_bug.cgi?id=5356 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |WONTFIX Status|UNCONFIRMED |RESOLVED Target Milestone|2.7.0 |--- --- Comment #6 from Quanah Gibson-Mount <quanah(a)openldap.org> --- This only really applies to a slapadd for cn=config now that back-bdb/hdb are retired. In that case just do a recursive chown -R on the config db after running slapadd. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 5277] Feature request: Impose SSL/TLS for some addresses/interfaces
by openldap-its＠openldap.org 09 Oct '23

09 Oct '23

https://bugs.openldap.org/show_bug.cgi?id=5277 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |VERIFIED -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 5277] Feature request: Impose SSL/TLS for some addresses/interfaces
by openldap-its＠openldap.org 09 Oct '23

09 Oct '23

https://bugs.openldap.org/show_bug.cgi?id=5277 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |SUSPENDED Status|UNCONFIRMED |RESOLVED Target Milestone|2.7.0 |--- --- Comment #2 from Quanah Gibson-Mount <quanah(a)openldap.org> --- patches welcome -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 5271] size limit by ip (feature request)
by openldap-its＠openldap.org 09 Oct '23

09 Oct '23

https://bugs.openldap.org/show_bug.cgi?id=5271 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |VERIFIED -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 5271] size limit by ip (feature request)
by openldap-its＠openldap.org 09 Oct '23

09 Oct '23

https://bugs.openldap.org/show_bug.cgi?id=5271 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|2.7.0 |--- Resolution|--- |SUSPENDED Status|UNCONFIRMED |RESOLVED --- Comment #3 from Quanah Gibson-Mount <quanah(a)openldap.org> --- patch welcome -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 10108] New: "mdb_dump -a" does not dump the main database
by openldap-its＠openldap.org 09 Oct '23

09 Oct '23

https://bugs.openldap.org/show_bug.cgi?id=10108 Issue ID: 10108 Summary: "mdb_dump -a" does not dump the main database Product: LMDB Version: 0.9.29 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: tuukka.pensala(a)gmail.com Target Milestone: --- In mdb_dump.c we have these instructions: /* -a: dump main DB and all subDBs * -s: dump only the named subDB * -n: use NOSUBDIR flag on env_open * -p: use printable characters * -f: write to file instead of stdout * -V: print version and exit * (default) dump only the main DB */ However, contrary to the description, the option -a does not dump the main DB. With argument -a "dumpit(..)" is called for the named databases, but not for the unnamed one. With the current behavior, if the data store contains subDBs and has user-added data in the main DB, there seems to be no way to dump all of it at once using mdb_dump. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 10107] New: Update support page with updated procedures to request a listing.
by openldap-its＠openldap.org 03 Oct '23

03 Oct '23

https://bugs.openldap.org/show_bug.cgi?id=10107 Issue ID: 10107 Summary: Update support page with updated procedures to request a listing. Product: website Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: website Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- Update the support page text at the bottom of the page on how to request a listing using the ITS system instead of email as currently is described. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 9735] New: [PATCH] try hard to find free space if database cannot grow
by openldap-its＠openldap.org 30 Sep '23

30 Sep '23

https://bugs.openldap.org/show_bug.cgi?id=9735 Issue ID: 9735 Summary: [PATCH] try hard to find free space if database cannot grow Product: LMDB Version: 0.9.24 Hardware: All OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: libor.peltan(a)nic.cz Target Milestone: --- Created attachment 851 --> https://bugs.openldap.org/attachment.cgi?id=851&action=edit Patch fixing the issue "try hard to find free space if database cannot grow" Note: - the issue is the same in version 0.9.70 (git) Situation: - the database had already grown to its limit (mapsize) in the past - overflow pages are used heavily as stored values are usually several pages long - free space got fragmented Problem: - attempt to insert new value results in MDB_MAP_FULL despite there is free space available Cause: there is a heursitic in mdb_page_alloc() that gives up searching for free space chunk if this would take too much time. This is useful when the database can still grow, as it balances performance with space usage. However, if the database can no longer grow, it prevents inserting new values. Solution: detect early on in mdb_page_alloc() if the database can grow, and if not, let it try hard to search for free space. Patch: attached -- You are receiving this mail because: You are on the CC list for the issue.

1 13

[Issue 10102] New: DB_LOCK_DEADLOCK
by openldap-its＠openldap.org 27 Sep '23

27 Sep '23

https://bugs.openldap.org/show_bug.cgi?id=10102 Issue ID: 10102 Summary: DB_LOCK_DEADLOCK Product: OpenLDAP Version: 2.4.23 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: daniel.hy.chan(a)pccw.com Target Milestone: --- We are getting "bdb_idl_insert_key: c_del failed: DB_LOCK_DEADLOCK: Locker killed to resolve a deadlock (-30995)" error in Openldap debug log. We are using Openldap.2.4.23 and have configured master-slave. It seems insert error. Please kindly help. -- You are receiving this mail because: You are on the CC list for the issue.

1 8

[Issue 10064] New: Add modrdn support for Cft_Misc entries
by openldap-its＠openldap.org 26 Sep '23

26 Sep '23

https://bugs.openldap.org/show_bug.cgi?id=10064 Issue ID: 10064 Summary: Add modrdn support for Cft_Misc entries 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: --- Currently in cn=config, there is some special handling to maintain overlays/dbs entries to allow list-like management. All module defined entries are marked Cft_Misc and this behaviour is not available there. It boils down to allowing the module to screen rename/renumber requests and having bconfig defer to that callback if it's defined. Use-case: policy selection rules in ITS#9343 would benefit from being managed this way rather than having to reparse a long line every time a rule is adjusted. -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 9471] New: Add RBAC overlay to core
by openldap-its＠openldap.org 26 Sep '23

26 Sep '23

https://bugs.openldap.org/show_bug.cgi?id=9471 Issue ID: 9471 Summary: Add RBAC overlay to core 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: --- Symas will contribute its RBAC overlay to core The slapo-rbac overlay is an implementation of the ANSI INCITS 359 Role-Based Access Control (RBAC) Core. When instantiated, it intercepts, decodes and enforces specific RBAC policies per the Apache Fortress RBAC data formats. The overlay provides a set of extended operations. They include session create/delete, checkAccess, addActiveRole, dropActiveRole and sessionRoles. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 9472] New: Add datamorph overlay to core
by openldap-its＠openldap.org 26 Sep '23

26 Sep '23

https://bugs.openldap.org/show_bug.cgi?id=9472 Issue ID: 9472 Summary: Add datamorph overlay to core 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: --- Symas will contribute its datamorph overlay to core The datamorph overlay to slapd allows attributes with a few predefined values to be saved more space-efficiently as well as signed or unsigned integer attributes. -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 9473] New: Add variant overlay to core
by openldap-its＠openldap.org 26 Sep '23

26 Sep '23

https://bugs.openldap.org/show_bug.cgi?id=9473 Issue ID: 9473 Summary: Add variant overlay to core 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: --- Symas will contribute its variant overlay to OpenLDAP core The variant overlay to slapd allows attributes/values to be shared between several entries. In some ways this is similar to slapo-collect with the exception that the source and target attributes can be different. -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 10087] New: slapd crashes with core dump Assertion `!LDAP_BACK_CONN_TAINTED( lc )
by openldap-its＠openldap.org 18 Sep '23

18 Sep '23

https://bugs.openldap.org/show_bug.cgi?id=10087 Issue ID: 10087 Summary: slapd crashes with core dump Assertion `!LDAP_BACK_CONN_TAINTED( lc ) Product: OpenLDAP Version: 2.5.15 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: rajko(a)albrecht.jetzt Target Milestone: --- The slapd daemon crashes every ten minutes with slapd: ../../../../../servers/slapd/back-ldap/bind.c:181: ldap_back_conn_delete: Assertion `!LDAP_BACK_CONN_TAINTED( lc )' failed. Aborted (core dumped) I searched around for multiple days but didn't find any solution to this problem. I have the same problem with 2.6.x versions. It is configured to act as caching ldap, while multiple hundred systems contact it. The error message is completely useless for sysadmins because they don't understand what this means for them (as said, asking search engines gives no answers) nor I don't know if - and if so how - I can fix this with configuration. I don't see if this message is talking about the connection to the upstream ldap server or if this is the connection from a client to the caching (and crashing) daemon. First setup was plain on a linux machine, now runnig inside docker environment so the service is restarted after the crash. This is of course not a nice solution. And it looks like the same like #4390 which is marked as "not solved". At least a description what this error messages means would be very helpful incl. how a workaround could look like (increasing timeouts, increase/decrease a socket pool or whatever). Currently the slapd is nearly useless when using it as a caching ldap with high load. Any hints? -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10096] New: SIGSEGV in try_read1msg() while using referrals with AD
by openldap-its＠openldap.org 18 Sep '23

18 Sep '23

https://bugs.openldap.org/show_bug.cgi?id=10096 Issue ID: 10096 Summary: SIGSEGV in try_read1msg() while using referrals with AD Product: OpenLDAP Version: 2.6.2 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: simon.pichugin(a)gmail.com Target Milestone: --- The double free happens during a referral chasing with AD. SSSD usage Background (But I think the issue can happen even without SSSD): Referral chasing with AD and Kerberos based GSSAPI/GSS-SPNEGO authentication will never work based in the fact that AD will return domain names instead of the names of AD DC in the referral. That with with 'id_provider = ad' (SSSD setting) there is 'ldap_referrals = false' as default. For 'id_provider = ldap' we expect a generic LDAP server (not AD) which returns proper referrals with fully-qualified hostname or where is simple bind is used, either anonymous or with bind DN and password (which is expected to be the same on all involved LDAP servers and which is not the case with AD since the AD DC from a different domain won't know the given bind DN). So the issue is an unusual one, but still, as it's a crash, I think it deserves a look at. The stack trace for the issue: #0 __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44 #1 0x00007f34182a15b3 in __pthread_kill_internal (signo=6, threadid=<optimized out>) at pthread_kill.c:78 #2 0x00007f3418254d46 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26 #3 0x00007f34182287f3 in __GI_abort () at abort.c:79 #4 0x00007f3418229130 in __libc_message (fmt=<optimized out>, fmt@entry=0x7f34183bb6bd "%s\n") at ../sysdeps/posix/libc_fatal.c:150 #5 0x00007f34182ab617 in malloc_printerr (str=str@entry=0x7f34183be2d0 "double free or corruption (!prev)") at malloc.c:5515 #6 0x00007f34182ad30c in _int_free (av=0x7f34183fac80 <main_arena>, p=0x560fc4b23130, have_lock=<optimized out>) at malloc.c:4458 #7 0x00007f34182af955 in __GI___libc_free (mem=<optimized out>) at malloc.c:3258 #8 0x00007f34173b6f52 in try_read1msg (result=0x7ffea107bb88, lc=0x560fc4ac20e0, all=0, msgid=-1, ld=0x560fc4a77450) at /usr/src/debug/openldap-2.6.2-3.el9.x86_64/openldap-2.6.2/libraries/libldap/result.c:919 #9 wait4msg (result=0x7ffea107bb88, timeout=<optimized out>, all=0, msgid=-1, ld=0x560fc4a77450) at /usr/src/debug/openldap-2.6.2-3.el9.x86_64/openldap-2.6.2/libraries/libldap/result.c:369 #10 ldap_result (ld=0x560fc4a77450, msgid=msgid@entry=-1, all=all@entry=0, timeout=timeout@entry=0x7ffea107bb90, result=result@entry=0x7ffea107bb88) at /usr/src/debug/openldap-2.6.2-3.el9.x86_64/openldap-2.6.2/libraries/libldap/result.c:120 #11 0x00007f3415b6f7be in sdap_process_result (ev=0x560fc49e2420, pvt=<optimized out>) at src/providers/ldap/sdap_async.c:233 #12 0x00007f3418433675 in tevent_common_invoke_fd_handler (fde=fde@entry=0x560fc4b07ce0, flags=1, removed=removed@entry=0x0) at ../../tevent_fd.c:142 #13 0x00007f34184373cf in epoll_event_loop (tvalp=0x7ffea107bc30, epoll_ev=0x560fc49e2700) at ../../tevent_epoll.c:737 #14 epoll_event_loop_once (ev=<optimized out>, location=<optimized out>) at ../../tevent_epoll.c:938 #15 0x00007f341842f6ab in std_event_loop_once (ev=0x560fc49e2420, location=0x7f3418575f10 "src/util/server.c:787") at ../../tevent_standard.c:110 #16 0x00007f3418431b88 in _tevent_loop_once (ev=ev@entry=0x560fc49e2420, location=location@entry=0x7f3418575f10 "src/util/server.c:787") at ../../tevent.c:825 #17 0x00007f3418431c7b in tevent_common_loop_wait (ev=0x560fc49e2420, location=0x7f3418575f10 "src/util/server.c:787") at ../../tevent.c:948 #18 0x00007f341842f71b in std_event_loop_wait (ev=0x560fc49e2420, location=0x7f3418575f10 "src/util/server.c:787") at ../../tevent_standard.c:141 #19 0x00007f3418552237 in server_loop (main_ctx=0x560fc49e2790) at src/util/server.c:787 #20 0x0000560fc371ebda in main (argc=8, argv=<optimized out>) at src/providers/data_provider_be.c:811 (gdb) frame 11 #11 0x00007f3415b6f7be in sdap_process_result (ev=0x560fc49e2420, pvt=<optimized out>) at src/providers/ldap/sdap_async.c:233 233 ret = ldap_result(sh->ldap, LDAP_RES_ANY, 0, &no_timeout, &msg); (gdb) frame 10 #10 ldap_result (ld=0x560fc4a77450, msgid=msgid@entry=-1, all=all@entry=0, timeout=timeout@entry=0x7ffea107bb90, result=result@entry=0x7ffea107bb88) at /usr/src/debug/openldap-2.6.2-3.el9.x86_64/openldap-2.6.2/libraries/libldap/result.c:120 120 rc = wait4msg( ld, msgid, all, timeout, result ); (gdb) frame 9 #9 wait4msg (result=0x7ffea107bb88, timeout=<optimized out>, all=0, msgid=-1, ld=0x560fc4a77450) at /usr/src/debug/openldap-2.6.2-3.el9.x86_64/openldap-2.6.2/libraries/libldap/result.c:369 369 rc = try_read1msg( ld, msgid, all, lc, result ); (gdb) frame 8 #8 0x00007f34173b6f52 in try_read1msg (result=0x7ffea107bb88, lc=0x560fc4ac20e0, all=0, msgid=-1, ld=0x560fc4a77450) at /usr/src/debug/openldap-2.6.2-3.el9.x86_64/openldap-2.6.2/libraries/libldap/result.c:919 919 ldap_return_request( ld, lr, 0 ); (gdb) frame 7 #7 0x00007f34182af955 in __GI___libc_free (mem=<optimized out>) at malloc.c:3258 3258 _int_free (ar_ptr, p, 0); (gdb) frame 6 #6 0x00007f34182ad30c in _int_free (av=0x7f34183fac80 <main_arena>, p=0x560fc4b23130, have_lock=<optimized out>) at malloc.c:4458 4458 malloc_printerr ("double free or corruption (!prev)"); (gdb) frame 8 #8 0x00007f34173b6f52 in try_read1msg (result=0x7ffea107bb88, lc=0x560fc4ac20e0, all=0, msgid=-1, ld=0x560fc4a77450) at /usr/src/debug/openldap-2.6.2-3.el9.x86_64/openldap-2.6.2/libraries/libldap/result.c:919 919 ldap_return_request( ld, lr, 0 ); (gdb) list 914 } 915 } 916 917 if ( lr != NULL ) { 918 if ( lr != &dummy_lr ) { 919 ldap_return_request( ld, lr, 0 ); 920 } 921 lr = NULL; 922 } 923 (gdb) p *ld $6 = {ldc = 0x560fc4b01110, ld_errno = 10, ld_error = 0x0, ld_matched = 0x0, ld_referrals = 0x0} (gdb) p *lr $8 = {lr_msgid = -995099056, lr_status = 22031, lr_refcnt = -995206016, lr_outrefcnt = 22030, lr_abandoned = 0, lr_origid = 40, lr_parentcnt = 4, lr_res_msgtype = 101, lr_res_errno = 0, lr_res_error = 0x0, lr_res_matched = 0x0, lr_ber = 0x0, lr_conn = 0x560fc4ac20e0, lr_dn = {bv_len = 20, bv_val = 0x560fc4affe6b "\304\017V"}, lr_parent = 0x0, lr_child = 0x560fc4adb650, lr_refnext = 0x0, lr_prev = 0x0, lr_next = 0x90} Thank you! Simon -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 10097] New: slapi didn't build on Windows
by openldap-its＠openldap.org 18 Sep '23

18 Sep '23

https://bugs.openldap.org/show_bug.cgi?id=10097 Issue ID: 10097 Summary: slapi didn't build on Windows Product: OpenLDAP Version: 2.6.6 Hardware: All OS: Windows Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- Apparently no one has ever tried to use SLAPI on Windows, since it has been broken ever since the initial commit in 2002. Fixed now in master, in 3489931553a684ab388b29dde0b8b2cf6cf63e79 and a7bd0416c80bcb954001c1b39512fb97f6c4b4ac -- You are receiving this mail because: You are on the CC list for the issue.

1 2

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs