openldap-bugs February 2024

openldap-bugs@openldap.org

1 participants
141 discussions

[Bug 9211] New: Relax control is not consistently access-restricted
by openldap-its＠openldap.org 06 May '26

06 May '26

https://bugs.openldap.org/show_bug.cgi?id=9211 Bug ID: 9211 Summary: Relax control is not consistently access-restricted Product: OpenLDAP Version: 2.4.49 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: ryan(a)openldap.org Target Milestone: --- The following operations can be performed by anyone having 'write' access (not even 'manage') using the Relax control: - modifying/replacing structural objectClass - adding/modifying OBSOLETE attributes Some operations are correctly restricted: - adding/modifying NO-USER-MODIFICATION attributes marked as manageable (Modification of non-conformant objects doesn't appear to be implemented at all.) In the absence of ACLs for controls, I'm of the opinion that all use of the Relax control should require manage access. The Relax draft clearly and repeatedly discusses its use cases in terms of directory _administrators_ temporarily relaxing constraints in order to accomplish a specific task. -- You are receiving this mail because: You are on the CC list for the bug.

1 14

[Issue 10163] New: Cleanup configure/test integration
by openldap-its＠openldap.org 06 May '26

06 May '26

https://bugs.openldap.org/show_bug.cgi?id=10163 Issue ID: 10163 Summary: Cleanup configure/test integration Product: OpenLDAP Version: 2.6.6 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- The sed commandline configure uses to perform substitutions is getting unwieldy and may be exceeding platform limits on various systems. All of the BUILD_xxx substitutions for overlays are only used in tests/run.in. They could be completely removed, and instead each of the enabled overlays could be emitted into a separate file that just gets included by the test scripts. There's no need for them to be part of the sed invocation at all. There's also leftover BUILD_xxx cruft from backends that we've removed (e.g. back-shell BUILD_SHELL) that nothing else in the tree references any more. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 9388] New: mdb_stat for DupSort DBI shows incorrect data
by openldap-its＠openldap.org 06 May '26

06 May '26

https://bugs.openldap.org/show_bug.cgi?id=9388 Issue ID: 9388 Summary: mdb_stat for DupSort DBI shows incorrect data Product: LMDB Version: 0.9.26 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: AskAlexSharov(a)gmail.com Target Milestone: --- It doesn't include pages pages used for values. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 10108] New: "mdb_dump -a" does not dump the main database
by openldap-its＠openldap.org 06 May '26

06 May '26

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 5

[Issue 9360] New: MDB_BAD_TXN: Transaction must abort, has a child, or is invalid
by openldap-its＠openldap.org 26 Apr '26

26 Apr '26

https://bugs.openldap.org/show_bug.cgi?id=9360 Issue ID: 9360 Summary: MDB_BAD_TXN: Transaction must abort, has a child, or is invalid Product: LMDB Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: spam(a)markandruth.co.uk Target Milestone: --- I have 2 python scripts writing to a database (lmdb 0.9.26, py-lmdb 0.98) and 5-10 lua processes (with lightningmdb module which uses lmdb 0.9.22) which are long-running serving queries from the database. The database seems fine, not corrupted, and the python writes still working all the time. But periodically (perhaps 10-20% of the time), in a way I am unable to reliably reproduce, when the lua starts up every time a query is issued txn dbi_open returns "MDB_BAD_TXN: Transaction must abort, has a child, or is invalid". A direct restart of the processes does not fix this issue, however stopping lua+python and then starting again after a 5-20s wait usually fixes the issue. This has been reproduced over multiple servers but I'm at a loss as to how to debug this any further? -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Bug 9208] New: LMDB feature request: variant of mdb_env_copy{,fd2} that takes transaction as parameter
by openldap-its＠openldap.org 24 Apr '26

24 Apr '26

https://bugs.openldap.org/show_bug.cgi?id=9208 Bug ID: 9208 Summary: LMDB feature request: variant of mdb_env_copy{,fd2} that takes transaction as parameter Product: LMDB Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: github(a)nicwatson.org Target Milestone: --- The mdb_env_copy* functions create a read transaction themselves to run the backup on. New variants of these functions (one for mdb_env_copy2 and one for mdb_env_copyfd2) would have a transaction parameter. This transaction would be used instead of creating a new transaction. Application code could use these new functions to synchronize consistent live backups across multiple LMDB instances (potentially across multiple hosts). -- You are receiving this mail because: You are on the CC list for the bug.

1 1

[Issue 10034] New: Assertion 'i < NUMKEYS(mp)' failed in mdb_page_search_root()"
by openldap-its＠openldap.org 23 Apr '26

23 Apr '26

https://bugs.openldap.org/show_bug.cgi?id=10034 Issue ID: 10034 Summary: Assertion 'i < NUMKEYS(mp)' failed in mdb_page_search_root()" Product: LMDB Version: 0.9.23 Hardware: Other OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: 763280032(a)qq.com Target Milestone: --- We found that when lmdb is opened after OS startup and data is written to it, lmdb will trigger abort probabilistically(Restart the OS 600 times will trigger once); We want to know what situation triggers this issue(Assertion 'i < NUMKEYS(mp)' failed in mdb_page_search_root()); we want to know if there is a problem with our usage; Please Help Us (gdb) x/8s 0x8baee988 0x8baee988: "8\373Բ\b\371Բmdb.c:5542: Assertion 'i < NUMKEYS(mp)' failed in mdb_page_search_root()" -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 9475] New: Add support for MAP_POPULATE
by openldap-its＠openldap.org 22 Apr '26

22 Apr '26

https://bugs.openldap.org/show_bug.cgi?id=9475 Issue ID: 9475 Summary: Add support for MAP_POPULATE Product: LMDB Version: unspecified Hardware: All OS: Linux Status: UNCONFIRMED Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: aa531811820(a)gmail.com Target Milestone: --- In some case (such as cloud computing platforms), the reading speed of large files is very fast while the small files is very slow, and we have enough memory, so we hope to prefetch the entire LMDB file into the memory during MMAP through the MAP_POPULATE flag . According to our test, this is faster than using readahead flag. Here are some test data: # mmap with no readahead read one sample: 0.2s total time: 4800s # mmap with readahead read one sample: 0.0001s~0.03s total time: 95.86s # mmap with MAP_POPULATE db init: 20s read one sample: 0.0001s total time: 78s -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 9397] New: LMDB: A second process opening a file with MDB_WRITEMAP can cause the first to SIGBUS
by openldap-its＠openldap.org 22 Apr '26

22 Apr '26

https://bugs.openldap.org/show_bug.cgi?id=9397 Issue ID: 9397 Summary: LMDB: A second process opening a file with MDB_WRITEMAP can cause the first to SIGBUS Product: LMDB Version: 0.9.26 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: github(a)nicwatson.org Target Milestone: --- Created attachment 780 --> https://bugs.openldap.org/attachment.cgi?id=780&action=edit Full reproduction of SIGBUS MDB_WRITEMAP issue (works on Linux only) The fundamental problem is that a ftruncate() on Linux that makes a file smaller will cause accesses past the new end of the file to SIGBUS (see the mmap man page). The sequence that causes a SIGBUS involves two processes. 1. The first process opens a new LMDB file with MDB_WRITEMAP. 2. The second process opens the same LMDB file with MDB_WRITEMAP and with an explicit map_size smaller than the first process's map size. * This causes an ftruncate that makes the underlying file *smaller*. 3. (Optional) The second process closes the environment and exits. 4. The first process opens a write transaction and writes a bunch of data. 5. The first process commits the transaction. This causes a memory read from the mapped memory that's now past the end of the file. On Linux, this triggers a SIGBUS. Attached is code that fully reproduces the problem on Linux. The most straightforward solution is to allow ftruncate to *reduce* the file size if it is the only reader. Another possibility is check the file size and ftruncate if necessary every time a write transaction is opened. A third possibility is to catch the SIGBUS signal. Repro note: I used clone() to create the subprocess to most straightforwardly demonstrate that the problem is not due to inherited file descriptors. The problem still manifests when the processes are completely independent. -- You are receiving this mail because: You are on the CC list for the issue.

1 11

[Bug 9207] New: Remove Moznss compatibility layer
by openldap-its＠openldap.org 22 Apr '26

22 Apr '26

https://bugs.openldap.org/show_bug.cgi?id=9207 Bug ID: 9207 Summary: Remove Moznss compatibility layer Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- For the 2.5 release, remove the MozNSS compatibility layer. -- You are receiving this mail because: You are on the CC list for the bug.

1 6

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs February 2024