March 2022 - openldap-bugs

[Issue 9468] New: slapd-ldap does anonymous bind even if rebind-as-user is set

by openldap-its＠openldap.org

https://bugs.openldap.org/show_bug.cgi?id=9468 Issue ID: 9468 Summary: slapd-ldap does anonymous bind even if rebind-as-user is set Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: tero.saarni(a)est.tech Target Milestone: --- When back-ldap retries bind operation after connection retry, it will do it as anonymous even if rebind-as-user is set to yes. Expected behavior is that (re)bind is done with user's credentials from the initial bind operation. I observed following (Warning: I might have understood details of the code incorrectly): When rebind-as-user is set and bind operation from client is processed, proxy will copy the credentials to ldapconn_t representing the remote LDAP connection. When remote LDAP connection is closed (e.g. by the proxy itself due to timeout), the bind credentials information is lost when freeing the old ldapconn_t. At this point, client still holds the connection to proxy and is unaware of the remote connection being lost. Proxy then re-establishes the connection and "synthetically" generates new bind itself, but since it does not have the credentials stored in memory anymore, it sends anonymous bind on behalf of the client. As a side effect, slapd currently crashes if remote server does not allow anonymous bind and responds with InvalidCredentials instead. The crash is due to assert(), which is handled in separate issue https://bugs.openldap.org/show_bug.cgi?id=9288 -- You are receiving this mail because: You are on the CC list for the issue.

8 months, 3 weeks

1
12
0 / 0

[Issue 9580] New: Refresh vs. accesslog in delta-MPR

by openldap-its＠openldap.org

https://bugs.openldap.org/show_bug.cgi?id=9580 Issue ID: 9580 Summary: Refresh vs. accesslog in delta-MPR Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: replication Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- A server consuming a plain syncrepl session (might be a delta-MMR refresh) still has to log the entries into accesslog, however that accesslog stops being capable of serving as a delta-sync source: - operation entryCSNs will be out-of-order - the changes logged will not be the intended modifications (e.g. if we fell back after a conflict, the conflicting entry will be replaced with the other version, other examples available) We need to deal with that somehow, at the very least we need to make sure the consumer will not take them at face value. We could record this in the accesslog root entry if we can detect when this starts and match it up with the final cookie, syncprov would still need some tweaks to understand it. We could mark the entries received this way and make sure delta-consumers treat them as "poison", as if they were running a plain syncrepl session themselves (not update contextCSN until that's finished, mark its own accesslog entries this way, ...). Anything like that needs guarantees that it will clean itself up once all of the real plain sessions finish otherwise we've lost delta-sync altogether. A different approach might or might not be needed for live delta-persist sessions replicating from a refreshing provider, but at least that syncprov has a way of detecting this live if it chooses to. -- You are receiving this mail because: You are on the CC list for the issue.

9 months, 1 week

1
11
0 / 0

[Issue 9799] New: Clearing pending ops on Bind

by openldap-its＠openldap.org

https://bugs.openldap.org/show_bug.cgi?id=9799 Issue ID: 9799 Summary: Clearing pending ops on Bind 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: --- When slapd receives some operations before it has started processing a queued bind, those get added into conn->c_ops_pending and c_n_pending_ops is updated accordingly. Bind then eventually invokes connection_abandon() which forgets to zero out c_n_pending_ops and the connection remains unusable forever. -- You are receiving this mail because: You are on the CC list for the issue.

9 months, 2 weeks

1
6
0 / 0

[Issue 9385] New: Opening an env with MDB_NOSUBDIR with no existing file returns error

by openldap-its＠openldap.org

https://bugs.openldap.org/show_bug.cgi?id=9385 Issue ID: 9385 Summary: Opening an env with MDB_NOSUBDIR with no existing file returns error Product: LMDB Version: unspecified Hardware: All OS: Mac OS Status: UNCONFIRMED Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: kriszyp(a)gmail.com Target Milestone: --- Created attachment 776 --> https://bugs.openldap.org/attachment.cgi?id=776&action=edit A fix to tolerate stat call on non-existing file Calling mdb_env_open with a file path to a file that doesn't exist yet, with MDB_NOSUBDIR on a non-Windows OS will return an error indicating that the file doesn't exist. This is supposed to create a new file, and works properly on the mdb.master branch, and still functions properly on Windows. The error is due to the stat() call in mdb_env_open prior to the file existing. I attached a patch that tolerates the absence of the file before checking if the file is on a block device. I am not sure if this is the appropriate fix, or if would be better to move this check later in mdb_env_open after the file is created, or alternately, determining the parent directory and calling stat on that. -- You are receiving this mail because: You are on the CC list for the issue.

10 months, 1 week

1
1
0 / 0

[Issue 9702] New: slapadd is missing -r chroot option

by openldap-its＠openldap.org

https://bugs.openldap.org/show_bug.cgi?id=9702 Issue ID: 9702 Summary: slapadd is missing -r chroot option Product: OpenLDAP Version: 2.5.7 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: dpa-openldap(a)aegee.org Target Milestone: --- I want to run slapd under chroot with the -r option. In order to initialize the setup, I want to use `slapadd -n0 configuration.ldif`. The configuration file contains mdb databases and these databases have `olcDbDirectory: ` paths. Since slapd will load the databases from the chroot environment, the directory names must be submitted to slapadd to be correct in the chroot environment. This means, that outside the chroot environment the directory paths are not correct. When I call `slapadd -n0 ` I get the error olcDbDirectory: value #0: invalid path: No such file or directory slapadd: could not add entry dn="olcDatabase={1}mdb,cn=config" (line=909): Closing DB... which means, that slapadd cannot open (outside the chrooted environment) the olcDbDirectory path. Thus slapadd shall first enter the chrooted environment, but it lacks option for this. Probably slapcat will also need this option to dump the databases. The chrooted environment is created specially for openldap, so it contains no tools. -- You are receiving this mail because: You are on the CC list for the issue.

10 months, 1 week

1
3
0 / 0

[Issue 9745] New: Local Logging - Timestamp Formatting

by openldap-its＠openldap.org

https://bugs.openldap.org/show_bug.cgi?id=9745 Issue ID: 9745 Summary: Local Logging - Timestamp Formatting Product: OpenLDAP Version: 2.6.0 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: gnoe(a)symas.com Target Milestone: --- Timestamps for log lines in the 2.6+ local logging feature are saved unformatted (ex: "618ae741.0f6eb63a"). This has the potential to break any log aggregation/analysis program like splunk that expect timestamps in syslog format. These timestamps should configurable in various syslog formats. -- You are receiving this mail because: You are on the CC list for the issue.

10 months, 1 week

1
13
0 / 0

[Issue 9403] New: add option to completely disable syslog logging

by openldap-its＠openldap.org

https://bugs.openldap.org/show_bug.cgi?id=9403 Issue ID: 9403 Summary: add option to completely disable syslog logging Product: OpenLDAP Version: 2.4.45 Hardware: All OS: Linux Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: cvuillemez(a)yahoo.fr Target Milestone: --- For auditing purpose, I need to enable "stats" loglevel. So on heavy load, slapd send lots of events to local syslog socket /dev/log, when compiled with LDAP_SYSLOG (on Debian / Ubuntu). It worked fine on old systems with a simple syslog service. But when upgrading on system with journald+syslog, CPU "overhead" becomes totally crazy. It would be great to have an option at run time to completely disable syslog logging, or/and use a cutom socket, e.g. /run/systemd/journal/syslog to bypass journald service. -- You are receiving this mail because: You are on the CC list for the issue.

10 months, 1 week

1
3
0 / 0

[Issue 9675] New: Allow overwriting the default SLAPD_DEFAULT_CONFIGDIR during ./configure

by openldap-its＠openldap.org

https://bugs.openldap.org/show_bug.cgi?id=9675 Issue ID: 9675 Summary: Allow overwriting the default SLAPD_DEFAULT_CONFIGDIR during ./configure Product: OpenLDAP Version: 2.5.7 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: dpa-openldap(a)aegee.org Target Milestone: --- Created attachment 839 --> https://bugs.openldap.org/attachment.cgi?id=839&action=edit fix I want to have different default for SLAPD_DEFAULT_CONFIGDIR in my slapd. By calling CPPFLAGS="-DSLAPD_DEFAULT_CONFIGDIR='\"/new/config/dir/\"'" ./configure one can change the default configdir in slapd. Provided that the macro SLAPD_DEFAULT_CONFIGDIR is not changed in the code, which is ensured by the provided patch. Macro SLAPD_DEFAULT_UCDATA is not used anywhere. -- You are receiving this mail because: You are on the CC list for the issue.

10 months, 2 weeks

1
7
0 / 0

[Issue 9436] New: OpenSSL 3.0: libldap uses depreciated functions

by openldap-its＠openldap.org

https://bugs.openldap.org/show_bug.cgi?id=9436 Issue ID: 9436 Summary: OpenSSL 3.0: libldap uses depreciated functions Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- OpenLDAP master fails to build against OpenSSL 3.0 alpha when "no-deprecated" is specified. Currently hitting these errors: ./.libs/libldap.so: undefined reference to `SSL_get_peer_certificate' ./.libs/libldap.so: undefined reference to `PEM_read_bio_DHparams' ./.libs/libldap.so: undefined reference to `ERR_get_error_line' ./.libs/libldap.so: undefined reference to `DH_free' ./.libs/libldap.so: undefined reference to `SSL_CTX_set_tmp_dh' Notes: SSL_get_peer_certificate is SSL_get1_peer_certificate in 3.0.0 SSL_CTX_set_tmp_dh should be replaced as follows: # define SSL_CTX_set_tmp_dh(ctx,dh) \ SSL_CTX_ctrl(ctx,SSL_CTRL_SET_TMP_DH,0,(char *)(dh)) Have to dig deeper for: PEM_read_bio_DHparams ERR_get_error_line DH_free -- You are receiving this mail because: You are on the CC list for the issue.

10 months, 2 weeks

1
16
0 / 0

[Issue 9814] New: upgrade ppm to 2.1 release

by openldap-its＠openldap.org

https://bugs.openldap.org/show_bug.cgi?id=9814 Issue ID: 9814 Summary: upgrade ppm to 2.1 release Product: OpenLDAP Version: 2.5.11 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: david.coutadeur(a)gmail.com Target Milestone: --- Hello, I have just opened two new MR to upgrade ppm to 2.1 release: * for OpenLDAP 2.5: https://git.openldap.org/openldap/openldap/-/merge_requests/509 * for OpenLDAP 2.6: https://git.openldap.org/openldap/openldap/-/merge_requests/510 Changes: - Reject password if it contains tokens from an attribute of the LDAP entry https://github.com/ltb-project/ppm/issues/17 -- You are receiving this mail because: You are on the CC list for the issue.

10 months, 2 weeks

1
8
0 / 0

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs March 2022