openldap-bugs April 2022

openldap-bugs@openldap.org

1 participants
117 discussions

[Issue 9818] New: slapo-translucent overlay crashes during wildcard search with subordinate
by openldap-its＠openldap.org 04 May '22

04 May '22

https://bugs.openldap.org/show_bug.cgi?id=9818 Issue ID: 9818 Summary: slapo-translucent overlay crashes during wildcard search with subordinate 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: jeremy.diaz(a)rexconsulting.net Target Milestone: --- I found that slapd 2.5.11 w/slapo-translucent will crash when queried with a wildcard search. It looks like any wildcard search on any attribute specified in "translucent_local" will cause the SIGSEGV on the latest version of Symas OpenLDAP slapd, 2.5.11, MDB databases, running on CentOS7. It seems that the SIGSEGV problem does not occur w the 2.4.44 from the RHEL7 distribution, and so the problem may have be a regression. I have not tested any other versions but have verified that, with the exact same config, the problem does not happen on the RHEL7 2.4.44 version, but does happen w/Symas OpenLDAP 2.5.11. It's an interesting config here. There are two database+suffixes defined in the instance. The first one is subordinate (ou=someorg,dc=corp,dc=com) to the second one (dc=corp,dc=com). The "subordinate" option is set to "True". The second database section loads the translucent overlay which is pointed to the upstream Active Directory instance and has the same suffix of AD. The problem is administrative. The group want their admins who manage LDAP data to be able to search using wildcard "cn=xyx*" filters. Besides crashing, we have noticed that these work, but only when setting the basedn of the subordinate database. I tried a few things in a test lab and was able to reproduce the issue. with "cn" in "translucent_local" and sublevel search of translucent superior basedn dc=corp,dc=com "(cn=jed)" filter returns subordinate database entry "(cn=je*)" filter crashes slapd with "cn" not in "translucent_local" and sublevel search of translucent superior basedn dc=corp,dc=com "(cn=jed)" filter return referrals from upstream Active Directory "(cn=je*)" filter return referrals from upstream Active Directory with "cn" in "translucent_local" and sublevel search of subordinate basedn ou=someorg,dc=corp,dc=com "(cn=jed)" filter returns subordinate database entry from ou=someorg "(cn=je*)" filter returns subordinate database entry(ies) from ou=someorg with "cn" not in "translucent_local" and sublevel search of subordinate dbasedn ou=someorg,dc=corp,dc=com "(cn=jed)" filter returns subordinate database entry from ou=someorg "(cn=je*)" filter returns subordinate database entry(ies) from ou=someorg Here's what the crash looks like: 622eb2f7.0393c4d6 0x7fcf15e89880 slapd starting 622eb2fd.32371976 0x7fce8d9f3700 slap_listener_activate(8): 622eb2fd.323bb364 0x7fce8d1f2700 >>> slap_listener(ldap:///) 622eb2fd.3247761c 0x7fce8d1f2700 connection_get(15): got connid=1000 622eb2fd.3247962c 0x7fce8d1f2700 connection_read(15): checking for input on id=1000 622eb2fd.3247b177 0x7fce8d1f2700 ber_get_next 622eb2fd.3247e0b8 0x7fce8d1f2700 ber_get_next: tag 0x30 len 12 contents: 622eb2fd.3247f6f1 0x7fce8d1f2700 op tag 0x60, time 1647227645 622eb2fd.32480615 0x7fce8d1f2700 ber_get_next 622eb2fd.32484eca 0x7fce8d1f2700 conn=1000 op=0 do_bind 622eb2fd.324861e8 0x7fce8d1f2700 ber_scanf fmt ({imt) ber: 622eb2fd.324871c1 0x7fce8d1f2700 ber_scanf fmt (m}) ber: 622eb2fd.32488890 0x7fce8d1f2700 >>> dnPrettyNormal: <> 622eb2fd.32489324 0x7fce8d1f2700 <<< dnPrettyNormal: <>, <> 622eb2fd.3248ce51 0x7fce8d1f2700 do_bind: version=3 dn="" method=128 622eb2fd.3248efc7 0x7fce8d1f2700 send_ldap_result: conn=1000 op=0 p=3 622eb2fd.324906be 0x7fce8d1f2700 send_ldap_response: msgid=1 tag=97 err=0 622eb2fd.32492605 0x7fce8d1f2700 ber_flush2: 14 bytes to sd 15 622eb2fd.324ab763 0x7fce8d1f2700 do_bind: v3 anonymous bind 622eb2fd.325dc3b4 0x7fce8d1f2700 connection_get(15): got connid=1000 622eb2fd.325de12a 0x7fce8d1f2700 connection_read(15): checking for input on id=1000 622eb2fd.325dec44 0x7fce8d1f2700 ber_get_next 622eb2fd.325e0856 0x7fce8d1f2700 ber_get_next: tag 0x30 len 63 contents: 622eb2fd.325e1663 0x7fce8d1f2700 op tag 0x63, time 1647227645 622eb2fd.325e22e8 0x7fce8d1f2700 ber_get_next 622eb2fd.325e500c 0x7fce8d1f2700 conn=1000 op=1 do_search 622eb2fd.325e5ae0 0x7fce8d1f2700 ber_scanf fmt ({miiiib) ber: 622eb2fd.325e69ea 0x7fce8d1f2700 >>> dnPrettyNormal: <dc=corp,dc=com> 622eb2fd.325e98bd 0x7fce8d1f2700 <<< dnPrettyNormal: <dc=corp,dc=com>, <dc=corp,dc=com> 622eb2fd.325eaad7 0x7fce8d1f2700 ber_scanf fmt ({m) ber: 622eb2fd.325ebce5 0x7fce8d1f2700 ber_scanf fmt (m) ber: 622eb2fd.325eddcb 0x7fce8d1f2700 ber_scanf fmt ({M}}) ber: 622eb2fd.325f334c 0x7fce8d1f2700 ==> limits_get: conn=1000 op=1 self="[anonymous]" this="dc=corp,dc=com" 622eb2fd.325f4dcc 0x7fce8d1f2700 ==> translucent_search: <dc=corp,dc=com> (cn=jed*) Segmentation fault Thanks! -- You are receiving this mail because: You are on the CC list for the issue.

1 8

[Issue 9785] New: test050 deadlock
by openldap-its＠openldap.org 04 May '22

04 May '22

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.

1 7

[Issue 9789] New: syncprov uses a thread-local counters for the detached op
by openldap-its＠openldap.org 04 May '22

04 May '22

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.

1 4

[Issue 9804] New: slapd.conf(5) - remove comment from syncrepl about sizelimit
by openldap-its＠openldap.org 04 May '22

04 May '22

https://bugs.openldap.org/show_bug.cgi?id=9804 Issue ID: 9804 Summary: slapd.conf(5) - remove comment from syncrepl about sizelimit Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: michael(a)stroeder.com Target Milestone: --- slapd.conf(5) and slapd-config(5) contain the following really mis-leading text: "The sizelimit and timelimit parameters define a consumer requested limitation on the number of entries that can be returned by the LDAP Content Synchronization operation; as such, it is intended to implement partial replication based on the size of the replicated database and on the time required by the synchronization." This is wrong. One cannot implement deterministic partial replication with these limits. => This text should be removed. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 9808] New: olcLastBind populated incorrectly when converting from slapd.conf
by openldap-its＠openldap.org 04 May '22

04 May '22

https://bugs.openldap.org/show_bug.cgi?id=9808 Issue ID: 9808 Summary: olcLastBind populated incorrectly when converting from slapd.conf 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: --- Fix coming shortly. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 9801] New: Segmentation Fault of Openldap 2.6.1 when the syncprov overlay tries to synchronize from ODSEE an attribute that it does not know.
by openldap-its＠openldap.org 04 May '22

04 May '22

https://bugs.openldap.org/show_bug.cgi?id=9801 Issue ID: 9801 Summary: Segmentation Fault of Openldap 2.6.1 when the syncprov overlay tries to synchronize from ODSEE an attribute that it does not know. 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: laurent.revillion(a)icloud.com Target Milestone: --- Created attachment 877 --> https://bugs.openldap.org/attachment.cgi?id=877&action=edit The files from gdb Hello, I just tested Opendlap 2.6.1 synchronization from ODSEE. It seemed to me that everything was going very well but I had a "Segmention Fault" when I tested on ODSEE to add the nsAccountLock: TRUE attribute. This attribute does not exist in the Openldap schema. The Openldap server detects the thing well but ... segmentation fault.:(( 620f6bd2.1b555d23 0x7fd0c9aff700 ldap_get_attribute_ber 620f6bd2.1b556639 0x7fd0c9aff700 ber_scanf fmt ({mM}) ber: 620f6bd2.1b5576f3 0x7fd0c9aff700 ldap_get_attribute_ber 620f6bd2.1b55b147 0x7fd0c9aff700 syncrepl_changelog_mods: rid=002 Invalid attribute nsAccountLock, attribute type undefined ./start-consumer1.sh : ligne 3 : 12531 Erreur de segmentation /opt/symas/lib/slapd -d 1 -u ldap -g ldap -h "ldap://:5389/" -f /opt/symas/config/static-test/slapd-dsee-consumer1.conf Attached are the files generated via gdb. Thanks Laurent -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 9584] New: cn=config replication ops/refresh should pause server
by openldap-its＠openldap.org 04 May '22

04 May '22

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.

1 18

[Issue 9791] New: Build failure with certain disabled features in openssl
by openldap-its＠openldap.org 04 May '22

04 May '22

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.

1 4

[Issue 9794] New: Define behaviour for pwdChangedTime modifications
by openldap-its＠openldap.org 04 May '22

04 May '22

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.

1 12

[Issue 9825] New: MemberOf group in group search not working
by openldap-its＠openldap.org 04 May '22

04 May '22

https://bugs.openldap.org/show_bug.cgi?id=9825 Issue ID: 9825 Summary: MemberOf group in group search not working 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: erikdewaard(a)gmail.com Target Milestone: --- Created attachment 891 --> https://bugs.openldap.org/attachment.cgi?id=891&action=edit database ldif dynlist group in group search not working correctly. Multiple queries needed before returning correct answer. ldapsearch -H ldap:/// -LLL -x -b 'dc=example,dc=com' '(&(uid=user1)(memberOf=cn=groupingroup,ou=groups,dc=example,dc=com))' uid ldapsearch -H ldap:/// -LLL -x -b 'dc=example,dc=com' '(&(uid=user1)(memberOf=cn=groupingroup,ou=groups,dc=example,dc=com))' uid ldapsearch -H ldap:/// -LLL -x -b 'dc=example,dc=com' '(&(uid=user1)(memberOf=cn=groupingroup,ou=groups,dc=example,dc=com))' uid dn: uid=user1,ou=People,dc=example,dc=com uid: user1 -conf # stand-alone slapd config include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/rfc2307bis.schema include /etc/openldap/schema/dyngroup.schema # allow big PDUs from anonymous (for testing purposes) sockbuf_max_incoming 4194303 moduleload back_ldap moduleload dynlist ####################################################################### # database definitions ####################################################################### database config database mdb suffix "dc=example,dc=com" rootdn "cn=Manager,dc=example,dc=com" rootpw secret directory /var/lib/ldap lastbind off overlay dynlist dynlist-attrset groupOfURLs memberURL uniqueMember+memberOf@groupOfUniqueNames* database monitor -- You are receiving this mail because: You are on the CC list for the issue.

1 6

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs April 2022