openldap-bugs

openldap-bugs@openldap.org

21001 discussions

[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

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