openldap-bugs January 2024

openldap-bugs@openldap.org

1 participants
88 discussions

[Issue 10074] New: lloadd: build broken with more recent versions of LLVM
by openldap-its＠openldap.org 29 Jan '24

29 Jan '24

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.

1 5

[Issue 10025] New: Add option to disable filtered searches for memberURL groups
by openldap-its＠openldap.org 29 Jan '24

29 Jan '24

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.

1 10

[Issue 10083] New: lload: Receiving a NoD while connection is closing already corrupts c_state
by openldap-its＠openldap.org 29 Jan '24

29 Jan '24

https://bugs.openldap.org/show_bug.cgi?id=10083 Issue ID: 10083 Summary: lload: Receiving a NoD while connection is closing already corrupts c_state 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: --- If the backend closes a connection with a NoD, two things happen: we won't be able to write to the socket and we receive the NoD message. lloadd might encounter those in either order, but handle_unsolicited() doesn't expect to be the second one to come in and happily overrides c_state, even if c_unlink() has been called by the write side already. upstream_destroy() eventually discovers the inconsistent state (LLOAD_C_CLOSING vs. LLOAD_C_DYING) and assert()s. A fix to handle_unsolicited() is coming. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10091] New: slapd segfaults when the dynlist overlay is applied on the frontend db (with `<memberOf-ad>@<static-oc>` parameters)
by openldap-its＠openldap.org 29 Jan '24

29 Jan '24

https://bugs.openldap.org/show_bug.cgi?id=10091 Issue ID: 10091 Summary: slapd segfaults when the dynlist overlay is applied on the frontend db (with `<memberOf-ad>@<static-oc>` parameters) Product: OpenLDAP Version: 2.6.6 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: philip.schildkamp(a)uni-koeln.de Target Milestone: --- Created attachment 974 --> https://bugs.openldap.org/attachment.cgi?id=974&action=edit Full stacktrace of the segfault Dear OpenLDAP Development-Team, first of all, thank You for Your continued efforts to provide this great software! I've run into a segfault when trying to apply the dynlist overlay to the frontend db. As I'm running Alpine Linux (based on musl libc), I've verified that this segfault also occurs under GLIBC-based distros. Furthermore, I've trimmed my config down to the bare minimum to provide a replicable setting. This segfault only occurs when I'm trying to use the full `dynlist-attrset` configuration (including the `+<memberOf-ad>@<static-oc>` parameters). If I only supply the `<group-oc> <URL-ad> <member-ad>` parts of the configruation, the segfault does not occur. And the segfault does not happen on startup, but when connecting to the running `slapd` instance. The version I'm running: > @(#) $OpenLDAP: slapd 2.6.6 (Aug 7 2023 12:57:03) $ My `slapd.conf` (the same segfault occures through a `cn=config` setup): > moduleload dynlist > > include /etc/openldap/schema/core.schema > > overlay dynlist > dynlist-attrset labeledURIObject labeledURI member+memberOf@groupOfNames > > database ldif > directory /tmp > suffix "dc=example,dc=com" I've attached a complete stacktrace of the segfault, which is traced back to `dynlist.c:2057`. If I can provide any other means of debugging (e.g. a coredump) or help in locating the root of this issue, I'd be happy to! If this issue is known or the dynlist overlay does not support this functionality on the frontend db, I'm sorry for the noise; but as far as I've been able to verify, there is no mention of such a limitation within the `slapo-dynlist` manpage (which does mention the possibility to apply the dynlist overlay to the frontend db), nor did I find an issue regarding exactly this error. Again, thank You for Your efforts and kind regards, Philip Schildkamp -- You are receiving this mail because: You are on the CC list for the issue.

1 8

[Issue 10070] New: Allow running when /etc/resolv.conf is missing
by openldap-its＠openldap.org 29 Jan '24

29 Jan '24

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.

1 5

[Issue 10089] New: regex that does not pass `regtest()` causes the entire process to exit
by openldap-its＠openldap.org 29 Jan '24

29 Jan '24

https://bugs.openldap.org/show_bug.cgi?id=10089 Issue ID: 10089 Summary: regex that does not pass `regtest()` causes the entire process to exit 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: --- There are 6 locations in `aclparse.c` in the function `parse_acl()` that call `regtest()` validating a regex expression before its use. Currently, when `regtest()` finds an issue it calls `exit()` and the process must be restarted. It seems that a better approach would be to allow the failures to be processed by the caller where the severity might be better understood. In some (most?) cases it's likely just fine for the process to continue after some information about the issue is logged and resources are released properly. https://git.openldap.org/openldap/openldap/-/blob/master/servers/slapd/aclp… -- You are receiving this mail because: You are on the CC list for the issue.

1 11

[Issue 10105] New: slapd logging fails to add newline with large search filters
by openldap-its＠openldap.org 29 Jan '24

29 Jan '24

https://bugs.openldap.org/show_bug.cgi?id=10105 Issue ID: 10105 Summary: slapd logging fails to add newline with large search filters 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: quanah(a)openldap.org Target Milestone: --- When using slapd logging rather than syslog, it fails to write a newline if the search filter is extremely long. Found this when examining the logs where the search filter has 500 users in it, in the form of: "(&(objectClass=userobject)(|(uid=abc)(uid=xyz)....)" In the slapd log, the filter gets truncated and the next log line is appended, so we end up with ...(uid=joe.hSep 27 18:21:09 hostname slapd[6373]: conn=1234 op=123 SEARCH RESULT tag=101 err=0 qtime=0.xxxx etime=0.xxx nentries=500 text= -- You are receiving this mail because: You are on the CC list for the issue.

1 9

[Issue 10145] New: ldap_url_parse_ext buffer overread
by openldap-its＠openldap.org 29 Jan '24

29 Jan '24

https://bugs.openldap.org/show_bug.cgi?id=10145 Issue ID: 10145 Summary: ldap_url_parse_ext buffer overread Product: OpenLDAP Version: 2.6.6 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: joshua(a)joshua.hu Target Milestone: --- Hi there, There is an easy-to-trigger buffer overread in the function ldap_url_parse_ext in libraries/libldap/url.c: 850 url_tmp = skip_url_prefix( url_in, &enclosed, &scheme ); 851 852 if ( url_tmp == NULL ) { 853 return LDAP_URL_ERR_BADSCHEME; 854 } 855 856 assert( scheme != NULL ); 857 858 proto = ldap_pvt_url_scheme2proto( scheme ); 859 if ( proto == -1 ) { 860 return LDAP_URL_ERR_BADSCHEME; 861 } 862 863 /* make working copy of the remainder of the URL */ 864 url = LDAP_STRDUP( url_tmp ); 865 if ( url == NULL ) { 866 return LDAP_URL_ERR_MEM; 867 } 868 869 if ( enclosed ) { 870 p = &url[strlen(url)-1]; 871 872 if( *p != '>' ) { 873 LDAP_FREE( url ); 874 return LDAP_URL_ERR_BADENCLOSURE; 875 } 876 877 *p = '\0'; 878 } The function skip_url_prefix, presented with a url_in that is exactly '<ldap://', will work towards line 870, which will set: p = &url[strlen(0)-1]; This causes a one-byte buffer overread. This issue can be triggered by calling ldap_url_parse_ext with a url of exactly "<ldap://". This issue can be triggered both through the library, and slapd. ================================================================= ==1986888==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x602000004c2f at pc 0x7ffff7eed3c2 bp 0x7fffffffde10 sp 0x7fffffffde08 READ of size 1 at 0x602000004c2f thread T0 #0 0x7ffff7eed3c1 in ldap_url_parse_ext /home/jrogers/openldap-clean/libraries/libldap/url.c:872:7 -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10124] New: olcTLSDHParamFile causes slapd general protection fault error:0 in libcrypto.so.3.0.7
by openldap-its＠openldap.org 29 Jan '24

29 Jan '24

https://bugs.openldap.org/show_bug.cgi?id=10124 Issue ID: 10124 Summary: olcTLSDHParamFile causes slapd general protection fault error:0 in libcrypto.so.3.0.7 Product: OpenLDAP Version: 2.5.16 Hardware: All OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: r.g.van.der.kleij(a)umail.leidenuniv.nl Target Milestone: --- I am not sure this is even an openldap bug, but just in case it is I report it here. I build openldap 2.5 from source on Rocky linux 9.2. The previous build version 2.5.14 would run fine, but 2.5.16 would crash at startup with error: kernel: traps: slapd[3909] general protection fault ip:7fea2f19f2d2 sp:7fff76b17c00 error:0 in libcrypto.so.3.0.7[7fea2f0ad000+25b000] Since even in full debug nothing was logged apart from this error I started eliminating configuration items, ending up with only the config below. A fresh slapd 2.5.14 would start with only this ldif slapadded, 2.5.16 would not on the same server. Leaving out olcTLSDHParamFile would cause everything to work again. I tried regenerating a fresh 2048 bit dhparam file instead of the 4096 I was using, but no difference. openssl dhparam -out ./dhparam.pem 2048 dn: cn=config objectClass: olcGlobal cn: config olcArgsFile: /var/run/scs-slapd/slapd.args olcDisallows: bind_anon olcLogLevel: stats sync olcPasswordCryptSaltFormat: $6$%.16s olcPasswordHash: {CRYPT} olcPidFile: /var/run/scs-slapd/slapd.pid olcRequires: authc olcTLSCACertificateFile: "/etc/scs/openldap/certs/ca_chain.pem" olcTLSCertificateFile: /etc/scs/openldap/certs/cert.pem olcTLSCertificateKeyFile: /etc/scs/openldap/certs/key.pem olcTLSCipherSuite: ECDHE-RSA-AES256-SHA384:AES256-SHA256:!RC4:HIGH:!MD5:!aNULL :!EDH:!EXP:!SSLV2:!eNULL olcTLSCRLCheck: none olcTLSVerifyClient: allow olcTLSDHParamFile: /etc/ssl/dhparam.pem olcTLSProtocolMin: 3.3 olcToolThreads: 2 Both openssl-devel and gnutls-devel were available on the build system, but as far as I can see openssl would be preferred when available and was indeed used. (I tried both --with-tls=auto and --with-tls=openssl ) Make test would finish without issues My configure options: ./configure --prefix=$SCS_TARGET --sysconfdir=$SCS_TARGET_ETC \ --enable-debug \ --enable-slapd \ --with-systemd \ --enable-modules \ --with-tls=auto \ --with-cyrus-sasl \ --with-argon2 \ --enable-crypt \ --enable-spasswd \ --enable-rlookups \ --enable-overlays=mod \ --enable-syncprov=yes \ --enable-accesslog=mod \ --enable-backends=mod \ --enable-mdb=yes \ --enable-ndb=no \ --enable-sql=no \ --enable-wt=no \ --disable-shell The results in the configure log: TLS_LIBS='-lssl -lcrypto' WITH_TLS='yes' WITH_TLS_TYPE='openssl' -- You are receiving this mail because: You are on the CC list for the issue.

1 8

[Issue 10135] New: dynlist (and maybe others) doesn't use the right overinst context in callbacks
by openldap-its＠openldap.org 29 Jan '24

29 Jan '24

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.

1 8

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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs January 2024