openldap-bugs April 2023

openldap-bugs@openldap.org

1 participants
96 discussions

[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 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 9813] New: Incompatibility between remoteauth and ppolicy overlays
by openldap-its＠openldap.org 05 Sep '23

05 Sep '23

https://bugs.openldap.org/show_bug.cgi?id=9813 Issue ID: 9813 Summary: Incompatibility between remoteauth and ppolicy overlays Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: thierry.pubellier(a)paris.fr Target Milestone: --- Hi, We are planning to use OpenLDAP as a proxy for some users in our Active Directory servers, using remoteauth overlay. We want this OpenLDAP instance to also implement an account lockout policy, preventing the lockout on our internal Active Directory servers. But there seems to be an incompatibility between remoteauth and ppolicy overlays : remoteauth won't remote authenticate a user if local userPassword attribute exists, while ppolicy overlay needs this attribute. Could there be a configuration parameter in ppolicy to allow lockout checks/modifications (which seemed to be the default behavior of OpenLDAP before ITS#7089) ? I can provide a patch if allowed. Thanks by advance, Best regards, Thierry -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 9827] New: Feature request for module argon2.so to support Argon2i, Argon2d, Argon2id
by openldap-its＠openldap.org 14 Aug '23

14 Aug '23

https://bugs.openldap.org/show_bug.cgi?id=9827 Issue ID: 9827 Summary: Feature request for module argon2.so to support Argon2i, Argon2d, Argon2id Product: OpenLDAP Version: 2.6.1 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: juergen.sprenger(a)swisscom.com Target Milestone: --- Hi, This is a feature request. I would like to be able to chooses between Argon2i, Argon2d and Argon2id in slappasswd like in argon2 command: # argon2 Usage: argon2 [-h] salt [-i|-d|-id] [-t iterations] [-m log2(memory in KiB) | -k memory in KiB] [-p parallelism] [-l hash length] [-e|-r] [-v (10|13)] Password is read from stdin Parameters: salt The salt to use, at least 8 characters -i Use Argon2i (this is the default) -d Use Argon2d instead of Argon2i -id Use Argon2id instead of Argon2i -t N Sets the number of iterations to N (default = 3) -m N Sets the memory usage of 2^N KiB (default 12) -k N Sets the memory usage of N KiB (default 4096) -p N Sets parallelism to N threads (default 1) -l N Sets hash output length to N bytes (default 32) -e Output only encoded hash -r Output only the raw bytes of the hash -v (10|13) Argon2 version (defaults to the most recent version, currently 13) -h Print argon2 usage Example: /usr/local/etc/openldap # /usr/sbin/slappasswd -h "{ARGON2}" -o module-load="argon2.so i" -s secret /usr/local/etc/openldap # /usr/sbin/slappasswd -h "{ARGON2}" -o module-load="argon2.so d" -s secret /usr/local/etc/openldap # /usr/sbin/slappasswd -h "{ARGON2}" -o module-load="argon2.so id" -s secret Best regards Juergen Sprenger -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 10042] New: Crash when back-monitor search fails/is abandoned
by openldap-its＠openldap.org 10 Jul '23

10 Jul '23

https://bugs.openldap.org/show_bug.cgi?id=10042 Issue ID: 10042 Summary: Crash when back-monitor search fails/is abandoned 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: --- The fix in ITS#9832 was incomplete, some paths leading to "freeout:" can have passed through monitor_cache_release already. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 9993] New: Potential race condition in back-mdb online indexer
by openldap-its＠openldap.org 10 Jul '23

10 Jul '23

https://bugs.openldap.org/show_bug.cgi?id=9993 Issue ID: 9993 Summary: Potential race condition in back-mdb online indexer Product: OpenLDAP Version: 2.5.13 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- When the online indexer completes, it should mutex-protect its resetting of the indexing flags. -- You are receiving this mail because: You are on the CC list for the issue.

1 9

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs April 2023