openldap-bugs

openldap-bugs@openldap.org

1 participants
20752 discussions

[Issue 10205] New: SSL handshake blocks forever in async mode if server unaccessible
by openldap-its＠openldap.org 25 Apr '24

25 Apr '24

https://bugs.openldap.org/show_bug.cgi?id=10205 Issue ID: 10205 Summary: SSL handshake blocks forever in async mode if server unaccessible Product: OpenLDAP Version: 2.5.17 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: regtube(a)hotmail.com Target Milestone: --- When ldaps:// scheme is used to connect to currently unaccessible server with LDAP_OPT_CONNECT_ASYNC and LDAP_OPT_NETWORK_TIMEOUT options set, it blocks forever on SSL_connect. Here is a trace: ldap_sasl_bind ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP winserv.test.net:636 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying 192.168.56.2:636 ldap_pvt_connect: fd: 3 tm: 30 async: -1 ldap_ndelay_on: 3 attempting to connect: connect errno: 115 ldap_int_poll: fd: 3 tm: 0 ldap_err2string [2024-04-25 15:41:27.112] [error] [:1] bind(): Connecting (X) [2024-04-25 15:41:27.112] [error] [:1] err: -18 ldap_sasl_bind ldap_send_initial_request ldap_int_poll: fd: 3 tm: 0 ldap_is_sock_ready: 3 ldap_ndelay_off: 3 TLS trace: SSL_connect:before SSL initialization TLS trace: SSL_connect:SSLv3/TLS write client hello Looks like it happens because non-blocking mode is cleared from the socket (ldap_ndelay_off) after the first poll for write, and non-blocking mode is never restored before attempt to do tls connect, because of the check that assumes that non-blocking mode has already been set for async mode: if ( !async ) { /* if async, this has already been set */ ber_sockbuf_ctrl( sb, LBER_SB_OPT_SET_NONBLOCK, (void*)1 ); } while in fact it was cleared. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 10204] New: Slapd crashes when attempting to use DN as constraint attribute
by openldap-its＠openldap.org 24 Apr '24

24 Apr '24

https://bugs.openldap.org/show_bug.cgi?id=10204 Issue ID: 10204 Summary: Slapd crashes when attempting to use DN as constraint attribute Product: OpenLDAP Version: 2.6.1 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: eresendiz(a)symas.com Target Milestone: --- Created attachment 1016 --> https://bugs.openldap.org/attachment.cgi?id=1016&action=edit Crash output When adding a to the constraint overlay with a constraintattribute that contains a 'dn' filter the slapd process crashes. Please see below for more detail. Very readily produceable with any kind of non-existent attribute specified in the attribute list. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 10203] New: no pkgconfig file included for liblmdb
by openldap-its＠openldap.org 19 Apr '24

19 Apr '24

https://bugs.openldap.org/show_bug.cgi?id=10203 Issue ID: 10203 Summary: no pkgconfig file included for liblmdb Product: LMDB Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: otto(a)drijf.net Target Milestone: --- liblmdb does not ship with a pkgconfig file. More and more build systems rely on presense of a pkgconfig file, so it would be nice if liblmdb installed oneone. An example: prefix=/usr/local exec_prefix=${prefix} libdir=${prefix}/lib includedir=${prefix}/include Name: lmdb Description: Lightning memory-mapped database: key-value data store URL: https://www.symas.com/symas-embedded-database-lmdb Version: 0.9.32 Libs: -L${libdir} -llmdb Cflags: -I${includedir} Thanks. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 10197] New: Back-meta and back-asyncmeta add a new target structure and increase the number of targets even if uri parsing fails
by openldap-its＠openldap.org 16 Apr '24

16 Apr '24

https://bugs.openldap.org/show_bug.cgi?id=10197 Issue ID: 10197 Summary: Back-meta and back-asyncmeta add a new target structure and increase the number of targets even if uri parsing fails Product: OpenLDAP Version: 2.6.7 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: --- This happens when a new target is added via cn=config. In asyncmeta's case it can lead to too many connection structures allocated, although it seems operational. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 10161] New: Move nested group support to its own overlay
by openldap-its＠openldap.org 16 Apr '24

16 Apr '24

https://bugs.openldap.org/show_bug.cgi?id=10161 Issue ID: 10161 Summary: Move nested group support to its own overlay Product: OpenLDAP Version: 2.6.6 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: enhancement Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- Adding the feature to dynlist has made that code overly complex, along with killing performance. -- You are receiving this mail because: You are on the CC list for the issue.

1 9

[Issue 10193] New: Asyncmeta starts more than one timeout loop per database
by openldap-its＠openldap.org 16 Apr '24

16 Apr '24

https://bugs.openldap.org/show_bug.cgi?id=10193 Issue ID: 10193 Summary: Asyncmeta starts more than one timeout loop per database Product: OpenLDAP Version: 2.6.7 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: --- By design, there should be always exactly one timeout loop task per database, it is a balance to make sure timeout checks do not throttle traffic processing. For some reason, there seems to be more than one. This is only visible if slapd is started with -dasyncmeta log level. -- You are receiving this mail because: You are on the CC list for the issue.

1 8

[Issue 10155] New: Invalid [aka FUZZ] -F and -T options can core dump ldapsearch
by openldap-its＠openldap.org 16 Apr '24

16 Apr '24

https://bugs.openldap.org/show_bug.cgi?id=10155 Issue ID: 10155 Summary: Invalid [aka FUZZ] -F and -T options can core dump ldapsearch Product: OpenLDAP Version: 2.6.6 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: client tools Assignee: bugs(a)openldap.org Reporter: doug.leavitt(a)oracle.com Target Milestone: --- A customer reported core dumps in ldapsearch which has been tracked to the the improper use of the -F and -T options. The customer confirmed removing the invalid -F and -T options from their script eliminated the core dumps. The CLI arguments of the failing ldapsearch look like: ldapsearch <good CLI args> -F , -T u <good filter and attr args> The good CLI args include proper uses of -H... -x -D ... -w ... -b ... -s ... The good filter and attrs are also valid CLI inputs. The "bad" args are <sp>-F<sp><COMMA><sp>-T<sp>-u<sp> The -u is also valid but it is consumed as a directory name of -T From man page and code review the the -F argument is supposed to be a valid URL. and the -T argument is supposed to be a valid directory The core file output indicates that main calls free after the search takes place. The location is believed to be here: 1658 if ( urlpre != NULL ) { 1659 if ( def_urlpre != urlpre ) 1660 free( def_urlpre ); <--------- 1661 free( urlpre ); 1662 } ... 1672 tool_exit( ld, rc ); ... This is the first example of the use of -F we have seen so it is unclear how this should be fixed. But code review of ldapsearch.c and common.c exposed a few weaknesses that could help in addressing the issue. Observed weaknesses: The getopt processing code for -T does not check that the arg is actually a directory and fail/error when bad input is provided. Perhaps at least an access(2) check should be performed? It is unclear if -F should only accept file:// URLs. The existing code does not sufficiently check any URL format instead it processes the argument by looking for the first '/' [no error checking] and determine the remainder to be a tmpdir location similar to the -T argument. So, Fuzz input of <COMMA> seems to eventually lead to the core files. It is unclear if -F and -T should be mutually exclusive or not. It seems like the fix to this issue is to add better error checking and to fail on FUZZ inputs. I defer a solution to upstream as it probably requires project direction I lack. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 9934] New: slapd-config(5) should document how to store certificates for slapd usage
by openldap-its＠openldap.org 16 Apr '24

16 Apr '24

https://bugs.openldap.org/show_bug.cgi?id=9934 Issue ID: 9934 Summary: slapd-config(5) should document how to store certificates for slapd usage Product: OpenLDAP Version: 2.5.13 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- Commit 7b41feed83b expanded the ability of cn=config to save the certificates used for TLS by slapd directly in the config database. However the documentation for the new parameters was never added to the slapd-config(5) man page. olcTLSCACertificate $ olcTLSCertificate $ olcTLSCertificateKey -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 10020] New: dynlist's @groupOfUniqueNames is considered only for the first configuration line
by openldap-its＠openldap.org 16 Apr '24

16 Apr '24

https://bugs.openldap.org/show_bug.cgi?id=10020 Issue ID: 10020 Summary: dynlist's @groupOfUniqueNames is considered only for the first configuration line Product: OpenLDAP Version: 2.5.13 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: msl(a)touk.pl Target Milestone: --- If we consider the following configuration of dynlist: {0}toukPerson labeledURI uniqueMember+memberOf@groupOfUniqueNames {1}groupOfURLs memberURL uniqueMember+dgMemberOf@groupOfUniqueNames The {0} entry will correctly populate the memberOf relatively to static group membership. The {1} entry will produce dgMemberOf with dynamic group membership correctly (based on memberURL query) but it will not populate static entries IF {0} entry in configuration is present. IF I remove {0} from the dynlist configuration - or - remove @groupOfUniqueNames part from this configuration line, then both dynamic and static entries will be populated correctly for {1}. So the effects are as follows on some user entry: if both {0} and {1} are present - {1} produced only dynamic groups: memberOf: cn=adm,ou=touk,ou=group,dc=touk,dc=pl memberOf: cn=touk,ou=touk,ou=group,dc=touk,dc=pl dgMemberOf: cn=dyntouk,ou=dyntest,ou=group,dc=touk,dc=pl if both {0} and {1} are present and @groupOfUniqueNames is removed from {0} - {1} produced static+dynamic groups: dgMemberOf: cn=adm,ou=touk,ou=group,dc=touk,dc=pl dgMemberOf: cn=touk,ou=touk,ou=group,dc=touk,dc=pl dgMemberOf: cn=dyntouk,ou=dyntest,ou=group,dc=touk,dc=pl If only {1} is present - {1} produced static+dynamic groups: dgMemberOf: cn=adm,ou=touk,ou=group,dc=touk,dc=pl dgMemberOf: cn=touk,ou=touk,ou=group,dc=touk,dc=pl dgMemberOf: cn=dyntouk,ou=dyntest,ou=group,dc=touk,dc=pl For completness - if only {0} is present: memberOf: cn=adm,ou=touk,ou=group,dc=touk,dc=pl memberOf: cn=touk,ou=touk,ou=group,dc=touk,dc=pl I would expect this behavior to be correct for the first case - {0} and {1}. memberOf: cn=adm,ou=touk,ou=group,dc=touk,dc=pl memberOf: cn=touk,ou=touk,ou=group,dc=touk,dc=pl dgMemberOf: cn=dyntouk,ou=dyntest,ou=group,dc=touk,dc=pl dgMemberOf: cn=adm,ou=touk,ou=group,dc=touk,dc=pl dgMemberOf: cn=touk,ou=touk,ou=group,dc=touk,dc=pl -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 10026] New: Refresh handling can skip entries (si_dirty not managed properly)
by openldap-its＠openldap.org 16 Apr '24

16 Apr '24

https://bugs.openldap.org/show_bug.cgi?id=10026 Issue ID: 10026 Summary: Refresh handling can skip entries (si_dirty not managed properly) 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: --- Take MPR plain syncrepl with 3+ providers. When a provider's own syncrepl session transitions to persist and a it starts a new parallel session towards another host, that session always has to start as a refresh. If that refresh serves entries to us, our handling of si_dirty is not consistent: - if the existing persist session serves some of these entries to us, we can "forget" to pass the others to a newly connected consumer - same if the refresh is abandoned and we start refreshing from a different provider that might be behind what we were being served (again our consumers could suffer) - if we restart, si_dirty is forgotten and our consumers suffer even worse We might need to be told (at the beginning of the refresh?) what the end state we're going for is, so we can keep si_dirty on until then. And somehow persist that knowledge in the DB... -- You are receiving this mail because: You are on the CC list for the issue.

1 7

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs