openldap-bugs August 2023

openldap-bugs@openldap.org

1 participants
112 discussions

[Issue 10093] New: Unclear licenses in certain places
by openldap-its＠openldap.org 14 Sep '23

14 Sep '23

https://bugs.openldap.org/show_bug.cgi?id=10093 Issue ID: 10093 Summary: Unclear licenses in certain places Product: OpenLDAP Version: 2.6.6 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: thegeorg(a)yandex-team.com Target Milestone: --- We use scancode-toolkit in order to perform automatic license analysis. At the time, this toolkit reports certain places with unclear license status. In particular, libraries/libldap/modrdn.c (lines 19 to 24) bear the following notice: ``` /* Copyright 1999, Juan C. Gomez, All rights reserved. * This software is not subject to any license of Silicon Graphics * Inc. or Purdue University. * * Redistribution and use in source and binary forms are permitted * without restriction or fee of any kind as long as this notice * is preserved. */ ``` While copyright notice is completely fine, the second part can not be recognised as any SPDX acknowledged license. Is it possible to unify the text across other parts of OpenLDAP? -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 10058] New: destroying robust mutexes leads to use of an uninitialized mutex
by openldap-its＠openldap.org 27 Aug '23

27 Aug '23

https://bugs.openldap.org/show_bug.cgi?id=10058 Issue ID: 10058 Summary: destroying robust mutexes leads to use of an uninitialized mutex Product: LMDB Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: jiri.novosad(a)gmail.com Target Milestone: --- Created attachment 966 --> https://bugs.openldap.org/attachment.cgi?id=966&action=edit an example program to reproduce the bug This is a regression introduced in https://bugs.openldap.org/show_bug.cgi?id=9278 . The issue is that mdb_env_setup_locks initializes the mutex only when it gets an exclusive fcntl file lock. But there is this possible order of operations: 1. Process A opens the DB, gets an exclusive file lock, initializes the mutex, downgrades the file lock to shared and does its thing 2. Process A closes the env: it gets an exclusive lock and destroys the mutex 3. Process B opens the DB and blocks in mdb_env_excl_lock trying to get the shared lock 4. Process A finishes closing the env, closes the file descriptor and loses the file lock 5. Process B gets the shared lock, does not initialize the mutex in mdb_env_setup_locks (because it does not have the exclusive lock) 6. Process B tries to lock the mutex, but it is not initialized, pthread_mutex_lock returns EINVAL -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 6166] Overlay/backend restructuring
by openldap-its＠openldap.org 24 Aug '23

24 Aug '23

https://bugs.openldap.org/show_bug.cgi?id=6166 Ondřej Kuzník <ondra(a)mistotebe.net> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.openldap.org/s | |how_bug.cgi?id=10080 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

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

21 Aug '23

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

1 0

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

18 Aug '23

https://bugs.openldap.org/show_bug.cgi?id=7226 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|olcAuditlogFile At dos not |olcAuditlogFile should be |accept multiple values |single valued, but accepts | |multiple values (additional | |values ignored) -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 7226] olcAuditlogFile At dos not accept multiple values
by openldap-its＠openldap.org 18 Aug '23

18 Aug '23

https://bugs.openldap.org/show_bug.cgi?id=7226 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|VERIFIED |CONFIRMED Resolution|FEEDBACK |--- --- Comment #17 from Quanah Gibson-Mount <quanah(a)openldap.org> --- Root problem of this being treated as single value, but accepting multiple values (additional values are ignored) has never been addressed, which was the original bug report here. The matching rule issue was already fixed. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 10086] New: test059 does not set up valid cn=config replication
by openldap-its＠openldap.org 14 Aug '23

14 Aug '23

https://bugs.openldap.org/show_bug.cgi?id=10086 Issue ID: 10086 Summary: test059 does not set up valid cn=config replication Product: OpenLDAP Version: 2.6.4 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: test suite Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- For cn=config replication to be valid, the entryUUIDs must match throughout the config database. However, this is not the case when test059 executes. The entryUUID for 'dn: cn=config' differs between the two. Example: quanah@apito1:~/git/quanah/openldap-scratch/tests/testrun$ grep entryUUID: cfcon.d/cn\=config.ldif entryUUID: aea058c4-bf6e-103d-9e18-4582986e9372 quanah@apito1:~/git/quanah/openldap-scratch/tests/testrun$ grep entryUUID: db.1.a/cn\=config\,cn\=consumer.ldif entryUUID: ae9bd858-bf6e-103d-871e-5daccf782d22 -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 10090] New: regex that contains a quoted literal space or escaped space results in a parse error
by openldap-its＠openldap.org 14 Aug '23

14 Aug '23

https://bugs.openldap.org/show_bug.cgi?id=10090 Issue ID: 10090 Summary: regex that contains a quoted literal space or escaped space results in a parse error Product: OpenLDAP Version: 2.6.6 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: gburd(a)symas.com Target Milestone: --- Searching ACLs using regex expressions should allow for white space. olcAccess: to dn.subtree="dc=example,dc=com" by dn.regex="ou=Before\ After,o=example[.]com,c=US$" read by * break or olcAccess: to dn.subtree="dc=example,dc=com" by dn.regex="ou=Before[ ]After,o=example[.]com,c=US$" read by * break or any regex that contains a literal space results in a parse error. It seems like the string is broken on literal spaces irrespective of quoting. Debug output from slapd: 64cd845c.253aa590 0x7fe6f4fc9640 slapd: line 0: regular expression "ou=Before\" bad because of Trailing backslash This should also include other methods for expressing white space such as `:space:` or `\w` pattern matches. olcAccess: to dn.subtree="dc=example,dc=com" by dn.regex="ou=Before[[:space:]]After,o=example[.]com,c=US$" read by * break -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10073] New: database monitor | slapd fails to start when "database ldap" without suffix exists
by openldap-its＠openldap.org 14 Aug '23

14 Aug '23

https://bugs.openldap.org/show_bug.cgi?id=10073 Issue ID: 10073 Summary: database monitor | slapd fails to start when "database ldap" without suffix exists Product: OpenLDAP Version: 2.5.14 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: cyusedfzfb(a)gmail.com Target Milestone: --- As requested on the mailinglist, I am filing an issue for this behaviour: Today setup the cn=Monitor backend, and after doing so, openldap failed to start with: backend_startup_one (type=monitor, suffix="cn=Monitor"): bi_db_open failed! (-1) The reason turned out to be: we had configured one of our databases ("database ldap") without a suffix. After I added a suffix, openldap started, and cn=Monitor worked as expected. It would be nice if this error message could become a little bit more specific. :-) Also: we've had the "database ldap" without a suffix in production working for many years. Perhaps cn=Monitor should be able to deal with that config as well..? -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10088] New: "DN index add failed" when renaming an entry
by openldap-its＠openldap.org 08 Aug '23

08 Aug '23

https://bugs.openldap.org/show_bug.cgi?id=10088 Issue ID: 10088 Summary: "DN index add failed" when renaming an entry 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: git(a)zifbang.com Target Milestone: --- I recently updated a Docker image to the latest Debian release, which means I got a new OpenLDAP version: 2.5.13 (not sure what it was before, but definitely <=2.4.x). The old image's backend was HDB. That disappeared, so I made changes(1) to use the default MDB store. Today I found out that one of my tests is failing against this new image with a "DN index add failed" message. I traced the message down to (2), but I don't understand what is causing the message to be generated and cannot find any documentation on the function that returned the error. Basically, the test is renaming an entry to a very long name. This script shows the error: ```sh #!/usr/bin/env bash set -e function cleanup() { echo "Stopping server..." docker stop ldap-test 2>&1 1>/dev/null } trap cleanup EXIT echo "Starting server..." docker run --rm -d \ -p 1389:389 -p 1636:636 \ --name ldap-test \ ghcr.io/ldapjs/docker-test-openldap/openldap:2023-07-25 2>&1 1>/dev/null echo "Waiting for server to start..." sleep 3 echo "Renaming entry..." docker exec ldap-test \ ldapmodrdn -x -H ldapi:/// \ -D 'cn=admin,dc=planetexpress,dc=com' \ -w 'GoodNewsEveryone' \ -v -d 2 \ 'cn=Turanga Leela,ou=people,dc=planetexpress,dc=com' \ 'cn=a292979f2c86d513d48bbb9786b564b3c5228146e5ba46f404724e322544a7304a2b1049168803a5485e2d57a544c6a0d860af91330acb77e5907a9e601ad1227e80e0dc50abe963b47a004f2c90f570450d0e920d15436fdc771e3bdac0487a9735473ed3a79361d1778d7e53a7fb0e5f01f97a75ef05837d1d5496fc86968ff47fcb64' ``` What changes do I need to make in order to solve this error? I have tried applying the following ldif to my image creation, but it does not solve the problem: ```ldif dn: cn=config changetype: modify replace: oldIndexHash64 olcIndexHash64: TRUE ``` 1: https://github.com/ldapjs/docker-test-openldap/pull/3/files 2: https://git.openldap.org/openldap/openldap/-/blob/2738a32de3a324fc56effd44c… -- You are receiving this mail because: You are on the CC list for the issue.

1 15

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs August 2023