January 2022 - openldap-bugs

by openldap-its＠openldap.org

https://bugs.openldap.org/show_bug.cgi?id=9785 Issue ID: 9785 Summary: test050 deadlock Product: OpenLDAP Version: 2.5.11 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: --- Running test050 in a loop sometimes results in a deadlock. Took 17 iterations on one system, was 100% on another. -- You are receiving this mail because: You are on the CC list for the issue.

10 months, 3 weeks

1
7
0 / 0

[Issue 9789] New: syncprov uses a thread-local counters for the detached op

by openldap-its＠openldap.org

https://bugs.openldap.org/show_bug.cgi?id=9789 Issue ID: 9789 Summary: syncprov uses a thread-local counters for the detached op 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: --- Persistent searches routinely migrate across threads, however they keep using op->o_counters from the original search op which is meant to be thread-local. During shutdown, this counter can be destroyed as the original thread finishes, but the persistent search might still be live somewhere else. At that point, trying to acquire the destroyed sc_mutex fails and the thread usually stalls forever. slapd-asyncmeta is very likely to suffer from the same issues. A representative backtrace of this happening: Thread 3 (Thread 0x7f0b7d933640 (LWP 2928392) "slapd"): #0 futex_wait (private=0, expected=2, futex_word=0x7f0b74000ff8) at ../sysdeps/nptl/futex-internal.h:146 #3 0x00007f0b7fd17a05 in ldap_pvt_thread_mutex_lock (mutex=Locked by LWP 0) at thr_posix.c:313 #4 0x0000000000469564 in slap_send_search_entry (op=Search request conn=1003 op=1 = {...}, rs=Search entry = {...}) at result.c:1503 #5 0x00007f0b7f30561c in syncprov_sendresp (op=Search request conn=1003 op=1 = {...}, ri=0x7f0b701eb8e0, so=0x7f0b74102b20, mode=1) at syncprov.c:976 #6 0x00007f0b7f305064 in syncprov_qplay (op=Search request conn=1003 op=1 = {...}, so=0x7f0b74102b20) at syncprov.c:1028 #7 0x00007f0b7f304ecc in syncprov_qtask (ctx=0x7f0b7d932a58, arg=0x7f0b74102b20) at syncprov.c:1086 -- You are receiving this mail because: You are on the CC list for the issue.

10 months, 3 weeks

1
4
0 / 0

[Issue 9584] New: cn=config replication ops/refresh should pause server

by openldap-its＠openldap.org

https://bugs.openldap.org/show_bug.cgi?id=9584 Issue ID: 9584 Summary: cn=config replication ops/refresh should pause server 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: --- Looking into this crash: https://git.openldap.org/openldap/openldap/-/jobs/7286 The thread in question is running a plain syncrepl refresh while another thread seems to have done the same. This thread fetched the entryUUID attribute of the 'cn=config' entry as 'a' and in the meantime, that entry has been rewritten, with 'a' presumably cleaned up and returned to the pool, so addressing a->a_nvals[0] is a NULL-dereference now. This might or might not be related to the fix in ITS#8102. -- You are receiving this mail because: You are on the CC list for the issue.

10 months, 3 weeks

1
18
0 / 0

[Issue 9791] New: Build failure with certain disabled features in openssl

by openldap-its＠openldap.org

https://bugs.openldap.org/show_bug.cgi?id=9791 Issue ID: 9791 Summary: Build failure with certain disabled features in openssl Product: OpenLDAP Version: 2.6.1 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: orgads(a)gmail.com Target Milestone: --- If openssl is configured with either OPENSSL_NO_MD4 or OPENSSL_NO_MD5 the build fails. -- You are receiving this mail because: You are on the CC list for the issue.

10 months, 3 weeks

1
4
0 / 0

[Issue 9794] New: Define behaviour for pwdChangedTime modifications

by openldap-its＠openldap.org

https://bugs.openldap.org/show_bug.cgi?id=9794 Issue ID: 9794 Summary: Define behaviour for pwdChangedTime modifications Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: david.coutadeur(a)gmail.com Target Milestone: --- This issue applies to: - draft-behera-ldap-password-policy - openldap 2.5 - openldap 2.6 It is a proposition of behaviour for pwdChangedTime modifications. modification of the draft: -------------------------- In section: "8.2.7. Policy State Updates", change this paragraph: If the value of either pwdMaxAge or pwdMinAge is non-zero, the server updates the pwdChangedTime attribute on the entry to the current time. into: If the value of either pwdMaxAge or pwdMinAge is non-zero, the server MUST update the pwdChangedTime attribute on the entry according to this workflow: Then insert a new paragraph: - if the current operation (add or modify) on the password includes adding or modifying a valid pwdChangedTime attribute, then use this pwdChangedTime. A "Valid" pwdChangedTime means a syntactically correct value, compliant with the schema, approved by access rules, and MAY require a relax control according to the schema defined in section 5.3.2. See Relax control RFC for more information: https://datatracker.ietf.org/doc/html/draft-zeilenga-ldap-relax - an invalid pwdChangedTime value MUST result in an error, and the pwdChangedTime MUST NOT be stored - in any other case, compute the current date and store it in a GeneralizedTime format Feel free to comment or propose other ideas. modification of the code: -------------------------- If this behaviour makes a consensus, it would be useful to patch both OpenLDAP 2.5 and 2.6. NOTE: current OpenLDAP 2.5 allows modifying pwdChangedTime alone, but fails to add a user with both userPassword and pwdChangedTime (it results in a duplicated pwdChangedTime error) modification of the documentation: ---------------------------------- In slapo-ppolicy, it can be useful to add a comment in "OPERATIONAL ATTRIBUTES" section: Every attribute defined as "NO-USER-MODIFICATION" SHOULD not be written by standard users. If needed, an administrator MAY modify them with the relax control. See Relax control RFC for more information: https://datatracker.ietf.org/doc/html/draft-zeilenga-ldap-relax -- You are receiving this mail because: You are on the CC list for the issue.

10 months, 3 weeks

1
12
0 / 0

[Issue 9620] New: back-monitor: search can access a persistent entry freed in the meantime

by openldap-its＠openldap.org

https://bugs.openldap.org/show_bug.cgi?id=9620 Issue ID: 9620 Summary: back-monitor: search can access a persistent entry freed in the meantime Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- With ITS#9600 there is now code that adds and removes "persistent" monitor entries outside a server pause. A concurrent cn=monitor search lists all children first and sends them later - monitor is happy to free some of them in the meantime. It seems to me that the monitor cache should be protected by a rw mutex instead, which would be held for reading while a search is happening. -- You are receiving this mail because: You are on the CC list for the issue.

11 months

1
11
0 / 0

[Issue 9784] New: Adding our OpenLDAP support services

by openldap-its＠openldap.org

https://bugs.openldap.org/show_bug.cgi?id=9784 Issue ID: 9784 Summary: Adding our OpenLDAP support services Product: website Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: website Assignee: bugs(a)openldap.org Reporter: contact(a)linuxstans.com Target Milestone: --- Hi, We offer OpenLDAP support and we'd really appreciate it if you can add our details to your support page https://www.openldap.org/support/ Here are the details: <a href="https://linuxstans.com/support/">Linux Stans</a> - USA Provides installation, configuration, maintenance, and 24/7 support services for OpenLDAP. Let me know if you need more info. Thanks! -- You are receiving this mail because: You are on the CC list for the issue.

11 months, 1 week

1
6
0 / 0

[Issue 9497] New: back-ldif: test022-ppolicy failure

by openldap-its＠openldap.org

https://bugs.openldap.org/show_bug.cgi?id=9497 Issue ID: 9497 Summary: back-ldif: test022-ppolicy failure Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: hamano(a)osstech.co.jp Target Milestone: --- The test022-ppolicy with back-ldif fail for two issue. 1. too short pwdMaxAge ~~~ $ ./run -b ldif test022-ppolicy (snip) Testing password expiration Waiting seconds for password to expire... sleep: missing operand Try 'sleep --help' for more information. Password expiration test failed ~~~ The script tries test for lockout and then a test for password expiration. It will fail if the password has expired(pwdMaxAge: 30) by the time it starts the password expiration test. This is a timing issue and not directly caused by back-ldif. However, the issue is reproduced only with back-ldif in my environment. This test passed in my environment by extending pwdMaxAge by 5 seconds, but there may be a better way. 2. duplicate ldap control response ~~~ Reconfiguring policy to remove grace logins... Clearing forced reset... expr: syntax error: unexpected argument '15' Testing password expiration Waiting seconds for password to expire... sleep: missing operand Try 'sleep --help' for more information. ~~~ This is back-ldif issue. back-ldif responds duplicate ldap control response. -- You are receiving this mail because: You are on the CC list for the issue.

1 year

1
8
0 / 0

[Issue 9748] New: Deleted values of pwdFailureTime seem to reappear

by openldap-its＠openldap.org

https://bugs.openldap.org/show_bug.cgi?id=9748 Issue ID: 9748 Summary: Deleted values of pwdFailureTime seem to reappear 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: --- Created attachment 854 --> https://bugs.openldap.org/attachment.cgi?id=854&action=edit accesslog for uid=dm01-R2H2-956,ou=People,dc=example,dc=com Somehow, ppolicy seems to be able to reference values of pwdFailureTime that had been deleted before the actual bind even started. In the attached accesslog, trace, deletion of everything (including "20211115154510.478330Z") is recorded from reqSession: 3, then a bind comes in and the same value is explicitly removed again. -- You are receiving this mail because: You are on the CC list for the issue.

1 year

1
9
0 / 0

[Bug 9256] New: The ACLs required for SASL binding are not fully documented

by openldap-its＠openldap.org

https://bugs.openldap.org/show_bug.cgi?id=9256 Bug ID: 9256 Summary: The ACLs required for SASL binding are not fully documented Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: kop(a)karlpinc.com Target Milestone: --- Created attachment 727 --> https://bugs.openldap.org/attachment.cgi?id=727&action=edit Patch massaging the SASL binding requirement docs While some ACL requirements for SASL binding are documented, some are not. E.g, that olcAuthzRegexp requires =x on objectClass when direct DN mapping is not documented. Other requirements can be reasoned out based on the existing documentation, but this can be very difficult when unfamiliar with all the moving parts and the places they are documented. E.g. knowing that (objectClass=*) is the default filter, and that there's _always_ _some_ filter, and connecting this with ACLs required to do search-based SASL mapping. The attached patch brings all the SASL binding requirements together in one place in the docs and makes everything explicit. The word "SASL" is included, for those searching for that keyword. I, Karl O. Pinc, hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice. -- You are receiving this mail because: You are on the CC list for the bug.

1 year

1
27
0 / 0

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs January 2022