January 2022 - openldap-bugs

[Issue 9358] New: back-mdb may return accesslog entries out of order

by openldap-its＠openldap.org

https://bugs.openldap.org/show_bug.cgi?id=9358 Issue ID: 9358 Summary: back-mdb may return accesslog entries out of order Product: OpenLDAP Version: 2.4.53 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- back-mdb will usually return search entries in entryID order, but may do a dn traversal instead if the count of children is smaller than the count of search filter candidates. The RDNs are sorted in length order, not lexical order. For accesslog, all RDNs are of equal length but if they have trailing zeroes, the generalizedTime normalizer truncates them. Changing their lengths causes accesslog's timestamp-based RDNs to sort in the wrong order. The least intrusive fix is to override the syntax/normalizer for reqStart and reqEnd attributes to not truncate trailing zeroes. -- You are receiving this mail because: You are on the CC list for the issue.

1 year, 1 month

1
6
0 / 0

[Issue 9516] New: Argon2 configuration parameters with slappasswd

by openldap-its＠openldap.org

https://bugs.openldap.org/show_bug.cgi?id=9516 Issue ID: 9516 Summary: Argon2 configuration parameters with slappasswd Product: OpenLDAP Version: 2.4.58 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: gilbert.kowarzyk(a)servicenow.com Target Milestone: --- It is currently possible to generate an Argon2 hash using slappasswd as follows: slappasswd -h {ARGON2} -o module-load=pw-argon2 However, I believe that it is currently not possible to provide Argon2 configuration values for parameters "m", "t", and "p" when using slappasswd. If it is currently possible to provide these config parameters when using slappasswd, please add documentation for how to do so. Thanks in advance! -- You are receiving this mail because: You are on the CC list for the issue.

1 year, 1 month

1
7
0 / 0

[Issue 9596] New: Python test suite

by openldap-its＠openldap.org

https://bugs.openldap.org/show_bug.cgi?id=9596 Issue ID: 9596 Summary: Python test suite Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- The bash test suite is extremely limited, hard to write for and slow. We can't lose it as it is also portable, but something should be introduced for developers/CI on more modern systems and increase coverage. A Python 3 seed for one is in development in MR!347. -- You are receiving this mail because: You are on the CC list for the issue.

1 year, 1 month

1
7
0 / 0

[Issue 9726] New: Admin guide and man pages need better documentation on disabling syslog

by openldap-its＠openldap.org

https://bugs.openldap.org/show_bug.cgi?id=9726 Issue ID: 9726 Summary: Admin guide and man pages need better documentation on disabling syslog Product: OpenLDAP Version: 2.6.0 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: --- 2.6.0 added the new feature allowing using a logfile for all debug/loglevel messages and bypassing syslog entirely. However, there is no documentation on the new settings or examples of how to do this in the admin guide, and the man page sections on the new parameters for the logfile side do not note at when/how they enable bypassing syslog. -- You are receiving this mail because: You are on the CC list for the issue.

1 year, 2 months

1
30
0 / 0

[Issue 9782] New: regression test its8752 failure

by openldap-its＠openldap.org

https://bugs.openldap.org/show_bug.cgi?id=9782 Issue ID: 9782 Summary: regression test its8752 failure 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: --- If a contextCSN update (new cookie) goes from server A through server B to server C, server C will use that CSN to update entryCSN as well (which neither A nor B did). This fails the initial replication check. The issue has likely existed since deltasync was made possible, a version of this is confirmed at least in 2.4.60 onwards to current master. In principle, it is related to concerns raised in ITS#9580. -- You are receiving this mail because: You are on the CC list for the issue.

1 year, 2 months

1
4
0 / 0

[Issue 9534] New: Persistent test043 failures

by openldap-its＠openldap.org

https://bugs.openldap.org/show_bug.cgi?id=9534 Issue ID: 9534 Summary: Persistent test043 failures Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- In testing current RE25 as of 4/23/2021 (73b2769d05529a7d474661023f2c4f3a931417b2) test043 is sporadically failing. Examining the testrun log, it appears replication never even initiated. -- You are receiving this mail because: You are on the CC list for the issue.

1 year, 2 months

1
10
0 / 0

[Issue 9642] New: Adding a task to runqueue doesn't wake the main thread

by openldap-its＠openldap.org

https://bugs.openldap.org/show_bug.cgi?id=9642 Issue ID: 9642 Summary: Adding a task to runqueue doesn't wake the main thread Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- If a connection adds a new syncrepl stanza, that is not started until the main thread comes around to doing it. However if that thread is currently stuck in SLAP_EVENT_WAIT() and nothing else happens (like an unbind over the connection that modified the config), the task is never started. This can take a long time. No idea yet how to wake it up with/from ldap_pvt_runqueue_insert() given that sits within libldap and not really something that should be calling slap_wake_listener(). -- You are receiving this mail because: You are on the CC list for the issue.

1 year, 3 months

1
4
0 / 0

[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.

1 year, 3 months

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.

1 year, 3 months

1
11
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.

1 year, 4 months

1
1
0 / 0

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs January 2022