openldap-bugs August 2023

openldap-bugs@openldap.org

1 participants
161 discussions

[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 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 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 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 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 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

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 August 2023