https://bugs.openldap.org/show_bug.cgi?id=10014
Issue ID: 10014
Summary: TLS handle using MbedTLS
Product: OpenLDAP
Version: 2.6.4
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: contrib
Assignee: bugs(a)openldap.org
Reporter: johan.pascal(a)linphone.org
Target Milestone: ---
Created attachment 950
--> https://bugs.openldap.org/attachment.cgi?id=950&action=edit
Add a TLS handle using MbedTLS
Hi,
I wrote a TLS handle based on MbedTLS.
I attach the patch here but I can also put in on gitlab and make a merge
request there.
The patch contains the minimal modifications to build openldap using MbedTLS as
backend for TLS. You must run aclocal, autoheader amd autoconf to regenerate
the archived aclocal.m4, configure and include/portable.hin files.
This contribution was originally written for the linphone project, and
copyright belongs to Belledonne Communications SARL.
The attached file is derived from OpenLDAP Software. All of the modifications
to OpenLDAP Software represented in the following patch were developed by
Belledonne Communications SARL. Belledonne Communications SARL has not assigned
rights and/or interest in this work to any party. I, Johan Pascal am authorized
by Belledonne Communications, my employer, to release this work under the
following terms.
The attached modifications to OpenLDAP Software are subject to the following
notice:
Copyright 2010-2023 Belledonne Communications SARL
Redistribution and use in source and binary forms, with or without
modification, are permitted only as authorized by the OpenLDAP Public License.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10074
Issue ID: 10074
Summary: lloadd: build broken with more recent versions of LLVM
Product: OpenLDAP
Version: 2.6.4
Hardware: All
OS: FreeBSD
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: lloadd
Assignee: bugs(a)openldap.org
Reporter: delphij(a)freebsd.org
Target Milestone: ---
There are two issues preventing lloadd from building with more recent versions
of LLVM. These are discovered on FreeBSD but may affect other operating
systems too.
The first one is that ldap_pvt_thread_self is returning pthread_t (which is a
pointer of struct pthread) on FreeBSD, but evthread_set_id_callback was
expecting unsigned long.
A possible solution would be to create a wrapper for the function, like:
--- servers/lloadd/libevent_support.c.orig 2023-02-08 18:53:35 UTC
+++ servers/lloadd/libevent_support.c
@@ -131,6 +131,20 @@ lload_libevent_cond_timedwait(
return ldap_pvt_thread_cond_wait( cond, mutex );
}
+/*
+ * libevent2 expects the thread id has a type of unsigned long.
+ */
+static unsigned long
+lload_libevent_thread_self(void)
+{
+ unsigned long retval;
+ static_assert(sizeof(ldap_pvt_thread_t) <= sizeof(unsigned long),
+ "ldap_pvt_thread_t has to be smaller or equal to unsigned
long");
+
+ retval = (unsigned long)ldap_pvt_thread_self();
+ return (retval);
+}
+
int
lload_libevent_init( void )
{
@@ -152,7 +166,7 @@ lload_libevent_init( void )
evthread_set_lock_callbacks( &cbs );
evthread_set_condition_callbacks( &cond_cbs );
- evthread_set_id_callback( ldap_pvt_thread_self );
+ evthread_set_id_callback( lload_libevent_thread_self );
return 0;
}
Or, maybe the code should just use evthread_use_pthreads() instead? (It's not
very clear to me why we have the ldap_pvt_thread_self wrapper).
Another issue is that module_init.c is trying to assign config_generic_wrapper
to bi->bi_config:
module_init.c:154:19: error: incompatible function pointer types assigning to
'BI_config *' (aka 'int (*)(struct BackendInfo *, const char *, int, int, char
**)') from 'int (Backend *, const char *, int, int, char **)' (aka 'int (struct
BackendDB *, const char *, int, int, char **)')
[-Wincompatible-function-pointer-types]
bi->bi_config = config_generic_wrapper;
^ ~~~~~~~~~~~~~~~~~~~~~~
For other backends, it's used as bi_db_config. It seems that I can set
bi_config to NULL and bi_db_config to config_generic_wrapper, but it's not
clear to me what the original intention was...
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10025
Issue ID: 10025
Summary: Add option to disable filtered searches for memberURL
groups
Product: OpenLDAP
Version: 2.5.14
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: subbarao(a)computer.org
Target Milestone: ---
One of the changes from 2.4 to 2.5 is that dynlist groups are now returned with
(member=memberDN) searches. This is potentially appealing, but even with the
ITS#9929 performance improvements, given the number of dynlist groups we have,
search times are significantly impacted.
We'd like to be able to cleanly disable this feature and exclude dynlist groups
from (member=memberDN) filter consideration. The only way I've found so far is
to patch the dynlist code itself. What I'm currently doing is adding a continue
statement right above this line in dynlist_search():
https://git.openldap.org/openldap/openldap/-/blob/OPENLDAP_REL_ENG_2_5_14/s…
That way the member searches are excluded, but dynlists otherwise work as
expected.
Here is the dynlist config we're using, just basic support for
groupOfURLs/memberURL:
overlay dynlist
dynlist-attrset groupOfURLs memberURL member
I'd like to request a configurable option to exclude dynlists from
(member=memberDN) searches.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10070
Issue ID: 10070
Summary: Allow running when /etc/resolv.conf is missing
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: lloadd
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
A resolv.conf file might be missing, usually that means that no name services
are available (often in test environments) or in some container environments
where the resolver is assumed to run on localhost.
We should adopt the proposal discussed in
https://github.com/libevent/libevent/issues/1155#issuecomment-918826471 which
lets us honour the file if it exists but keep the libevent default, allowing to
deal with both cases, no name resolution is needed (all URIs are numeric) and
the implicit local resolver.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10057
Issue ID: 10057
Summary: slapo-homedir(5) incorrectly refers to olcArchivePath
instead of olcHomedirArchivePath
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: craig.balfour(a)gmail.com
Target Milestone: ---
The homedir overlay manual page, slapo-homedir(5), refers to attribute
olcArchivePath when the attribute is actually named olcHomedirArchivePath.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10068
Issue ID: 10068
Summary: back-null dies on shutdown when dosearch specified
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: ---
It copies the suffix DN pointer into its entry rather than doing a ber_dupbv.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10059
Issue ID: 10059
Summary: slapo-homedir(5) could benefit from an configuration
example
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: documentation
Assignee: bugs(a)openldap.org
Reporter: craig.balfour(a)gmail.com
Target Milestone: ---
Created attachment 967
--> https://bugs.openldap.org/attachment.cgi?id=967&action=edit
Patch
This module could do with an example of how to configure it.
Patch attached.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10076
Issue ID: 10076
Summary: suffixmassage in back-asyncmeta does not handle empty
remote suffix correctly
Product: OpenLDAP
Version: 2.6.4
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: ---
When configuring a suffixmassage directive on an asyncmeta database,
a configuration like:
suffixmassage "dc=example,dc=com" ""
causes search requests to return error 34 "Invalid DN", because the empty
remote suffix is massaged incorrectly, adding an unnecessary ",".
The issue applies only to asyncmeta, on other proxies it functions correctly.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10013
Issue ID: 10013
Summary: Some code (ppolicy, etc.) ignores
REP_CTRLS_MUSTBEFREED when touching rs->sr_ctrls
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: ---
Certain parts of the source indicate that rs->sr_ctrls shouldn't be
realloc'd/free'd unless REP_CTRLS_MUSTBEFREED is set, but then other parts of
slapd (slap_ctrl_whatFailed_add, glue_op_search?, ...) and overlays (ppolicy,
syncprov, ...) will blindly overwrite and/or realloc it.
slap_add_control() (an analog of slap_add_controls()) might be useful for this,
possibly alongside some way to free the other data kept around to streamline
the code other users need for correct operation.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9944
Issue ID: 9944
Summary: Reverting an olcDbACLBind statement breaks proxied
write operations
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: ---
On a system with olcDbIDAssertBind configured, and proxied authorizations
working correctly, an olcDbACLBind statement was added to the configuration for
lastbind support. However an incorrect identity was in place for the authzid
in the ACL bind statement which caused proxy authorization to fail. The change
was backed out (There was never any change to the olcDbIDAssertBind config
fragment) and after that, all write operations failed instead of being proxied,
with err=80. Restarting slapd fixed the issue, which indicates an underlying
problem in the cn=config db in reverting to the original working state.
--
You are receiving this mail because:
You are on the CC list for the issue.