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=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.
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.
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.
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.
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=10094
Issue ID: 10094
Summary: When TLSv1.3 only are set TLS connection does not work
Product: OpenLDAP
Version: 2.5.12
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: nikigen68(a)gmail.com
Target Milestone: ---
The configuration with only TLSv1.3 ciphers does not work
/etc/openldap/ldap.conf
...
TLS_CIPHER_SUITE
TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:TLS_AES_128_CCM_8_SHA256:TLS_AES_128_CCM_SHA256
TLS_PROTOCOL_MIN 3.4
Configuration works only if at least one TLSv1.2 cipher suite is added. Then
TLSv1.3 cipher is negotiated with the server.
Is there a known issue?
--
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=10101
Issue ID: 10101
Summary: Fix double file close when first TLS connection fails
Product: OpenLDAP
Version: 2.6.2
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: florin.crisan(a)axigen.com
Target Milestone: ---
Created attachment 981
--> https://bugs.openldap.org/attachment.cgi?id=981&action=edit
Proof of concept
1. ldap_initialize a connection with multiple URLs, the first one being
LDAPS. (For example: "ldaps://server,ldap://server").
The LDAPS connection needs to successfully open the TCP connection,
but fail during TLS negotiation.
2. When TLS negotiation fails, ldap_int_open_connection calls
ber_int_sb_close (which closes the connections attached to the sockbuf)
but fails to call ber_int_sb_destroy, so the TCP layers are still attached
to the sockbuf structure.
3. When the second connection is opened, a new TCP layer is added to the
sockbuf structure, but the existing one is still there. Both now point to
the updated sockbuf structure, with the new file descriptor.
4. When the connection is closed, the layers attached to the sockbuf close
the new file descriptor twice.
This may be the same problem as
https://lists.openldap.org/hyperkitty/list/openldap-devel@openldap.org/thre…
--
You are receiving this mail because:
You are on the CC list for the issue.