[Issue 9785] New: test050 deadlock
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
[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
[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
[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
[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
[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
[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
[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
[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
[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