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.
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.
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.
https://bugs.openldap.org/show_bug.cgi?id=10067
Issue ID: 10067
Summary: back-meta doesn't like an empty modify
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: backends
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
A modify like:
dn: <dn>
changetype: modify
sent to a back-meta DB will trigger an assert on ch_malloc(0). The code also
kind of takes liberty at equating free and ch_free, which could backfire under
some (extremely rare) circumstances.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10047
Issue ID: 10047
Summary: slapd SEGV after slapindex -q
Product: OpenLDAP
Version: 2.6.3
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 cn=config is replicated:
a) Added an equality index for an existing attribute
b) Stopped slapd after the change to the configuration had been replicated to
the server. The indexing process that was automatically kicked off by this had
been running for ~30 minutes before I stopped slapd
c) ran: slapindex -q -F /path/to/config -b <base> <attr>
d) started slapd
e) segfault
To verify it wasn't an overall data issue, I then:
a) slapcat the database
b) moved the problem database files aside for debugging
c) reloaded the database with slapadd -q
d) everything works fine
I will attach the gdb output to this ticket momentarily
--
You are receiving this mail because:
You are on the CC list for the issue.
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.
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.
https://bugs.openldap.org/show_bug.cgi?id=10063
Issue ID: 10063
Summary: Typo in configure.ac for SLAPD_DYNAMIC_PWMODS
Product: OpenLDAP
Version: 2.6.3
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: build
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
As noted in -technical discussion:
By the way, while looking at the code, I noticed a typo in configure.ac:
> if test "$ol_enable_argon2" = "yes" ; then
> SLAPD_DYNAMIC_PWMODS="$SLAPD_DYNAMIC_PWDMODS argon2.la"
> fi ^^ ^^^
It's referencing two different variables there, which is harmless today,
but will be a build bug once multiple password modules become available.
SLAPD_DYNAMIC_PWMODS is the correct one.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10039
Issue ID: 10039
Summary: configure fails to detect
SSL_export_keying_material_early with LibreSSL
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: build
Assignee: bugs(a)openldap.org
Reporter: orbea(a)riseup.net
Target Milestone: ---
Created attachment 957
--> https://bugs.openldap.org/attachment.cgi?id=957&action=edit
config.log
When configuring OpenLDAP using --with-tls=openssl with LibreSSL the configure
will fail to detect SSL_export_keying_material_early since LibreSSL doesn't
support this function yet. However OpenLDAP doesn't actually use this function
so this can be easily solved by checking for SSL_library_init which is a more
standard function which both OpenSSL and LibreSSL support which OpenLDAP
actually uses in libraries/libldap/tls_o.c.
checking openssl/ssl.h usability... yes
checking openssl/ssl.h presence... yes
checking for openssl/ssl.h... yes
checking for SSL_export_keying_material_early in -lssl... no
configure: error: Could not locate TLS/SSL package
Other than this the build succeeds correctly with at least LibreSSL 3.7.
--
You are receiving this mail because:
You are on the CC list for the issue.