https://bugs.openldap.org/show_bug.cgi?id=10227
Issue ID: 10227
Summary: Asyncmeta will not reset a connection if a bind
operation fails with LDAP_OTHER, leaving the
connection in invalid state
Product: OpenLDAP
Version: 2.6.8
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: backends
Assignee: bugs(a)openldap.org
Reporter: nivanova(a)symas.com
Target Milestone: ---
The issue is difficult to reproduce, it can happen under heavy traffic if the
target is configured to do a sasl bind with a custom saslmech. In any case,
currently asyncmeta only resets the connection of the error is
LDAP_UNAVAILABLE, which is incorrect.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10219
Issue ID: 10219
Summary: Modify of olcDisabled by removing and adding a value
invokes db_open twice
Product: OpenLDAP
Version: 2.6.7
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: nivanova(a)symas.com
Target Milestone: ---
A database is enabled by default, and therefore a missing olcDisabled attribute
is equivalent to a value of FALSE. This means that currently a modify operation
that removes a olcDisabled value will invoke the db_open handler for that
database, even if in the same modify operation a value of TRUE is added.
A modify operation like this:
dn: olcDatabase={1}asyncmeta,cn=config
changetype: modify
delete: olcDisabled
olcDisabled: FALSE
-
add: olcDisabled
olcDisabled: TRUE
-
will call both db_open and db_close. This could be potentially harmful if the
backend type allocates memory on db_open like asyncmeta, for example. It is a
rare case, but it is best to fix it just in case.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10224
Issue ID: 10224
Summary: tlso_session_pinning: return codes from EVP* calls are
not checked; can result in crashes or undefined
behavior in library
Product: OpenLDAP
Version: 2.6.7
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: yaneurabeya(a)gmail.com
Target Milestone: ---
EVP* calls made in tlso_session_pinning on lines 1189-1191 [1] are not checked
when computing the digest which is eventually placed in `keyhash.bv_val` on
line [2].
Not checking the EVP* calls can result in undefined behavior, e.g., a library
crash with SIGBUS, SIGSEGV, etc, and/or incorrect results when analyzing
`keyhash.bv_val` later.
The calls should be checked to avoid this scenario.
Reported by Coverity.
1.
https://github.com/openldap/openldap/blob/15edb3b30f2b6a3dbdf77cc42d39466d5…
2.
https://github.com/openldap/openldap/blob/15edb3b30f2b6a3dbdf77cc42d39466d5…
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10287
Issue ID: 10287
Summary: Add test case for mdb_get
Product: LMDB
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: liblmdb
Assignee: bugs(a)openldap.org
Reporter: ahmed.zaki(a)imperial.ac.uk
Target Milestone: ---
Added a new file mtest7.c which tests the export mdb_get().
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=7249
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|2.6.9 |2.6.10
--- Comment #20 from Quanah Gibson-Mount <quanah(a)openldap.org> ---
Need to see if a fix similar to what was done in 10135 needs doing here
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10135
Issue ID: 10135
Summary: dynlist (and maybe others) doesn't use the right
overinst context in callbacks
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
Running the test suite with `-fsanitize=address` picks up a bug in
https://git.openldap.org/openldap/openldap/-/blob/860b61f41dfeeb19cc0eb011f…
Here, op->o_bd->bd_info isn't actually dynlist but mdb's own static bi, so
overlay_entry_get_ov then reaches into the void when reading on->on_info.
It's very likely that other places/overlays share the same bug as it is subtle
and doesn't get picked up immediately (slap_overinst embeds a BackendInfo and
oi_orig is not often set).
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=7249
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
See Also| |https://bugs.openldap.org/s
| |how_bug.cgi?id=10135
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10071
Issue ID: 10071
Summary: Extra sids in cookie should only be ignored for replay
consideration
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: ---
A consumer's cookie might contain sids that the provider is not aware of. Those
are currently screened out. This is appropriate for initial checks whether/how
to allow the operation to go ahead but might be needed for content
determination in refresh/persist. As such the cookie should be retained rather
than edited in place.
I don't have the logs from a failed test at hand but will post the
analysis/logs if I find them again.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10271
Issue ID: 10271
Summary: EINTR is handled as LDAP_SERVER_DOWN in socket
operation in ldap client APIs
Product: OpenLDAP
Version: 2.5.18
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: volan.shu(a)nokia.com
Target Milestone: ---
In case EINTR fired by OS in any case in ldap client api for socket related
operation, the ldap client API returns LDAP_SERVER_DOWN which is not correct.
In this case, I suppose the ldap client need retry socket operateion.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10284
Issue ID: 10284
Summary: RFE: retain subordinate entries to
cn=connections,cn=monitor branch for a configurable
duration
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: chris.paul(a)rexconsulting.net
Target Milestone: ---
Please consider an enhancement to retain entries under the
cn=connections,cn=monitor branch for a configurable duration. This would enable
monitoring of short-lived connections that currently disappear between polling
intervals, significantly increasing the utility of this metric for connection
tracking.
--
You are receiving this mail because:
You are on the CC list for the issue.