openldap-bugs September 2021

openldap-bugs@openldap.org

1 participants
203 discussions

[Issue 9666] New: 2.5 to 2.6 upgrade documentation
by openldap-its＠openldap.org 25 Oct '21

25 Oct '21

https://bugs.openldap.org/show_bug.cgi?id=9666 Issue ID: 9666 Summary: 2.5 to 2.6 upgrade documentation Product: OpenLDAP Version: unspecified 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: --- Need to document any upgrade issues for going from 2.5 to 2.6 -- You are receiving this mail because: You are on the CC list for the issue.

1 11

[Issue 9575] New: Object class olcGlobal should not allow olcPasswordHash
by openldap-its＠openldap.org 25 Oct '21

25 Oct '21

https://bugs.openldap.org/show_bug.cgi?id=9575 Issue ID: 9575 Summary: Object class olcGlobal should not allow olcPasswordHash Product: OpenLDAP Version: 2.5.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: michael(a)stroeder.com Target Milestone: --- Object class olcGlobal should not allow olcPasswordHash because slapd will crash during start if attribute is set. Reported in this thread: https://lists.openldap.org/hyperkitty/list/openldap-technical@openldap.org/… -- You are receiving this mail because: You are on the CC list for the issue.

1 9

[Issue 9536] New: back-asyncmeta crashes when traffic is directed to a new database, created via cn=config
by openldap-its＠openldap.org 25 Oct '21

25 Oct '21

https://bugs.openldap.org/show_bug.cgi?id=9536 Issue ID: 9536 Summary: back-asyncmeta crashes when traffic is directed to a new database, created via cn=config Product: OpenLDAP Version: unspecified Hardware: All OS: Linux Status: UNCONFIRMED Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: nivanova(a)symas.com Target Milestone: --- A new back-asyncmeta database is successfully created via cn=config, but the first LDAP request it tries to proxy causes a segmentation fault: 0# 0x00007F4C1E346629 in /usr/src/backend/src/main/c++/overlay-proxy/.libs/overlay_proxy-2.4.so.0 1# 0x00007F4C26D701E0 in /lib64/libc.so.6 2# pthread_mutex_lock in /lib64/libpthread.so.0 3# ldap_pvt_thread_mutex_lock in /usr/local/libexec/slapd 4# asyncmeta_getconn in /usr/local/libexec/slapd 5# asyncmeta_back_add in /usr/local/libexec/slapd 6# fe_op_add in /usr/local/libexec/slapd 7# overlay_op_walk in /usr/local/libexec/slapd 8# 0x00000000004D8EFB in /usr/local/libexec/slapd 9# 0x00000000004D90DC in /usr/local/libexec/slapd 10# do_add in /usr/local/libexec/slapd 11# 0x0000000000445B20 in /usr/local/libexec/slapd 12# 0x00000000004460FB in /usr/local/libexec/slapd 13# 0x0000000000563C54 in /usr/local/libexec/slapd 14# 0x00007F4C270FB569 in /lib64/libpthread.so.0 15# clone in /lib64/libc.so.6 -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 9581] New: Add precision setting for slapd lastbind setting
by openldap-its＠openldap.org 25 Oct '21

25 Oct '21

https://bugs.openldap.org/show_bug.cgi?id=9581 Issue ID: 9581 Summary: Add precision setting for slapd lastbind setting Product: OpenLDAP Version: 2.5.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- The lastbind functionality that was imported into slapd for 2.5 is missing the ability to fine tune the precision with which to allow the updates that was present in the original overlay. It would be nice to have an option for it. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 9615] New: ppolicy pwcheck module should be a configuration setting
by openldap-its＠openldap.org 25 Oct '21

25 Oct '21

https://bugs.openldap.org/show_bug.cgi?id=9615 Issue ID: 9615 Summary: ppolicy pwcheck module should be a configuration setting Product: OpenLDAP Version: 2.5.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- With the current implementation, the external pwcheck module for ppolicy is dl opened every time a given password policy is checked during a password modify operation. This appears to be problematic because eventually systems start reporting: check_password_quality: lt_dlopen failed: (ppm.so) file not found." There's really zero reason for this functionality to be implemented this way. Instead, an external password policy check module should be defined as a password policy config item, and then whether or not to use it remains a part of a given policy. This means the external module will only need to be opened a single time. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 9650] New: lloadd segfault on startup on systems using musl
by openldap-its＠openldap.org 25 Oct '21

25 Oct '21

https://bugs.openldap.org/show_bug.cgi?id=9650 Issue ID: 9650 Summary: lloadd segfault on startup on systems using musl Product: OpenLDAP Version: unspecified Hardware: All OS: Linux Status: UNCONFIRMED Severity: normal Priority: --- Component: lloadd Assignee: bugs(a)openldap.org Reporter: git(a)freundtech.com Target Milestone: --- I came across this problem while testing a fix for #9648. It seems to be unrelated, so I'm creating a separate issue. After compiling OpenLDAP 2.5.7 with the fix from #9648 and ----enable-balancer=yes on an Alpine Linux system lloadd segfaults on startup. The backtrace from a debug build is #0 0x00007ffff7fba852 in tss_get () from /lib/ld-musl-x86_64.so.1 #1 0x00005555555a844d in ldap_pvt_thread_key_getdata (key=0, data=0x7fffffffe820) at thr_posix.c:360 #2 0x00005555555a7f9f in ldap_pvt_thread_pool_context () at tpool.c:1442 #3 0x0000555555583122 in slap_sl_context (ptr=0x7ffff7f606e0) at sl_malloc.c:673 #4 0x0000555555580709 in ch_realloc (block=0x7ffff7f606e0, size=24) at ch_malloc.c:81 #5 0x0000555555572303 in lload_open_listener (url=0x7ffff7c43c30 "ldap:///", lud=0x7ffff7f60550, listeners=0x7fffffffeb1c, cur=0x7fffffffeb20) at daemon.c:465 #6 0x00005555555733bf in lloadd_listeners_init (urls=0x5555555d1958 "ldap:///") at daemon.c:749 #7 0x000055555557f7a9 in main (argc=1, argv=0x7fffffffed08) at main.c:632 The problem seems to be that ldap_pvt_thread_pool_context in tpool.c is called before ldap_int_thread_pool_startup in tpool.c is called. ldap_int_thread_pool_startup calls ldap_pvt_thread_key_create, which on posix calls pthread_key_create. ldap_pvt_thread_pool_context calls ldap_pvt_thread_key_getdata, which on posix calls pthread_getspecific. If ldap_int_thread_pool_startup wasn't called pthread_getspecific gets passed an uninitialized key, which is always 0 (because the variable is static). According to man 3 pthread_getspecific "The effect of calling pthread_getspecific() or pthread_setspecific() with a key value not obtained from pthread_key_create() or after key has been deleted with pthread_key_delete() is undefined." This seems to work fine on glibc, but crash on musl. -- You are receiving this mail because: You are on the CC list for the issue.

1 8

[Issue 9599] New: Additional balancing strategies for lloadd
by openldap-its＠openldap.org 25 Oct '21

25 Oct '21

https://bugs.openldap.org/show_bug.cgi?id=9599 Issue ID: 9599 Summary: Additional balancing strategies for lloadd Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: lloadd Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- At the moment, lloadd picks a backend on a round-robin basis, taking the first one that can deal with the request. This has several disadvantages: - there is no way to implement a failover set up where certain (e.g. local) servers should be contacted as a priority - all balancing is implicit on the limits imposed on servers - a connection/server is a candidate until we've reached those limits Allowing a priority and/or a different strategy to be set should address these. -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 9598] New: Restricted operation routing in lloadd
by openldap-its＠openldap.org 25 Oct '21

25 Oct '21

https://bugs.openldap.org/show_bug.cgi?id=9598 Issue ID: 9598 Summary: Restricted operation routing in lloadd Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: lloadd Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- Lloadd is not supposed to understand the LDAP protocol and is happy to route operations to whichever connection is available, but this can backfire in certain ways: - there are controls and extended operations that establish an shared context on the connection (paged results, TXN, ...) - it might take a measurable amount of time before a write operation is propagated to other servers There should be a way to force some of these to a chosen backend/upstream connection temporarily or even permanently based on the OID of the extop/control in question. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 9597] New: Send a Notice of Disconnection to clients
by openldap-its＠openldap.org 25 Oct '21

25 Oct '21

https://bugs.openldap.org/show_bug.cgi?id=9597 Issue ID: 9597 Summary: Send a Notice of Disconnection to clients Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: lloadd Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- When closing client connections, lloadd should try and send a NoD response first. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 9633] New: Intermittent test030 failure caused by referral chasing
by openldap-its＠openldap.org 25 Oct '21

25 Oct '21

https://bugs.openldap.org/show_bug.cgi?id=9633 Issue ID: 9633 Summary: Intermittent test030 failure caused by referral chasing Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- Not 100% reproducible but occurs frequently using ldif or wt backends. The test hits an assert failure in libldap. >>>>> Starting test030-relay for wt... running defines.sh Testing virtual naming context mapping with relay ldap meta backend(s)... Using relay backend... Starting slapd on TCP/IP port 9051... Using ldapsearch to check that slapd is running... Using ldapadd to populate the database... Searching base="dc=example,dc=com"... Searching base="o=Example,c=US"... Searching base="o=Esempio,c=IT"... Searching base="o=Beispiel,c=DE"... Modifying database "o=Beispiel,c=DE"... Modifying database "o=Example,c=US"... Searching base="o=Example,c=US"... Searching base="o=Esempio,c=IT"... Searching filter="(objectClass=referral)" attrs="'*' ref" base="dc=example,dc=com"... base="o=Example,c=US"... base="o=Esempio,c=IT"... Searching filter="(seeAlso=cn=all staff,ou=Groups,o=Example,c=US)" attrs="seeAlso" base="o=Example,c=US"... Searching filter="(uid=example)" attrs="uid" base="o=Example,c=US"... Searching filter="(member=cn=Another Added Group,ou=Groups,o=Example,c=US)" attrs="member" base="o=Example,c=US"... Filtering ldapsearch results... Filtering original ldif used to create database... Comparing filter output... Changing password to database "o=Example,c=US"... Binding with newly changed password to database "o=Beispiel,c=DE"... Comparing to database "o=Esempio,c=IT"... >>>>> waiting for things to exit Using ldap backend... Starting slapd on TCP/IP port 9051... Using ldapsearch to check that slapd is running... Using ldapadd to populate the database... Searching base="dc=example,dc=com"... Searching base="o=Example,c=US"... Searching base="o=Esempio,c=IT"... Searching base="o=Beispiel,c=DE"... Modifying database "o=Beispiel,c=DE"... Modifying database "o=Example,c=US"... Searching base="o=Example,c=US"... Search failed (255)! ../../head/tests/scripts/test030-relay: 240: kill: No such process >>>>> Failed test030-relay for wt after 3 seconds (exit 255) make[1]: Leaving directory '/home/hyc/OD/hobj/tests' backtrace: gdb) bt #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:49 #1 0x00007fb9119bd864 in __GI_abort () at abort.c:79 #2 0x00007fb9119bd749 in __assert_fail_base ( fmt=0x7fb911b46f78 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=0x7fb9123efc93 "lr->lr_refcnt == 0", file=0x7fb9123ef5c0 "../../../head/libraries/libldap/request.c", line=1671, function=<optimized out>) at assert.c:92 #3 0x00007fb9119cf3d6 in __GI___assert_fail ( assertion=0x7fb9123efc93 "lr->lr_refcnt == 0", file=0x7fb9123ef5c0 "../../../head/libraries/libldap/request.c", line=1671, function=0x7fb9123efe70 <__PRETTY_FUNCTION__.1> "ldap_find_request_by_msgid") at assert.c:101 #4 0x00007fb9121d671c in ldap_find_request_by_msgid (ld=0x7fb8fc124d70, msgid=3) at ../../../head/libraries/libldap/request.c:1671 #5 0x00007fb9121b882d in try_read1msg (ld=0x7fb8fc124d70, msgid=5, all=1, lc=0x7fb8fc128180, result=0x7fb90511bf48) at ../../../head/libraries/libldap/result.c:575 #6 0x00007fb9121b8135 in wait4msg (ld=0x7fb8fc124d70, msgid=5, all=1, timeout=0x7fb90511bf90, result=0x7fb90511bf48) at ../../../head/libraries/libldap/result.c:369 #7 0x00007fb9121b77cb in ldap_result (ld=0x7fb8fc124d70, msgid=5, all=1, timeout=0x7fb90511bf90, result=0x7fb90511bf48) --Type <RET> for more, q to quit, c to continue without paging-- at ../../../head/libraries/libldap/result.c:120 #8 0x00007fb9121d3b8c in ldap_new_connection (ld=0x7fb8fc124d70, srvlist=0x7fb90511c160, use_ldsb=0, connect=1, bind=0x7fb90511c1a0, m_req=1, m_res=1) at ../../../head/libraries/libldap/request.c:627 #9 0x00007fb9121d2ba0 in ldap_send_server_request (ld=0x7fb8fc124d70, ber=0x7fb8f0137ea0, msgid=4, parentreq=0x7fb8f0000fd0, srvlist=0x7fb90511c160, lc=0x0, bind=0x7fb90511c1a0, m_noconn=0, m_res=1) at ../../../head/libraries/libldap/request.c:253 #10 0x00007fb9121d56e5 in ldap_chase_v3referrals (ld=0x7fb8fc124d70, lr=0x7fb8f0000fd0, refs=0x0, sref=1, errstrp=0x7fb8f0001000, hadrefp=0x7fb90511c208) at ../../../head/libraries/libldap/request.c:1283 #11 0x00007fb9121b8b40 in try_read1msg (ld=0x7fb8fc124d70, msgid=3, all=0, lc=0x7fb8fc128180, result=0x7fb90511c4e8) at ../../../head/libraries/libldap/result.c:680 #12 0x00007fb9121b8135 in wait4msg (ld=0x7fb8fc124d70, msgid=3, all=0, timeout=0x7fb90511c520, result=0x7fb90511c4e8) at ../../../head/libraries/libldap/result.c:369 #13 0x00007fb9121b77cb in ldap_result (ld=0x7fb8fc124d70, msgid=3, all=0, timeout=0x7fb90511c520, result=0x7fb90511c4e8) at ../../../head/libraries/libldap/result.c:120 #14 0x000055a093724e35 in ldap_back_search (op=0x7fb8f0000be0, rs=0x7fb90511d990) at ../../../../head/servers/slapd/back-ldap/search.c:317 #15 0x000055a0936ff157 in overlay_op_walk (op=0x7fb8f0000be0, --Type <RET> for more, q to quit, c to continue without paging-- rs=0x7fb90511d990, which=op_search, oi=0x55a0943711d0, on=0x0) at ../../../head/servers/slapd/backover.c:706 #16 0x000055a0936ff417 in over_op_func (op=0x7fb8f0000be0, rs=0x7fb90511d990, which=op_search) at ../../../head/servers/slapd/backover.c:766 #17 0x000055a0936ff59b in over_op_search (op=0x7fb8f0000be0, rs=0x7fb90511d990) at ../../../head/servers/slapd/backover.c:796 #18 0x000055a09365d201 in fe_op_search (op=0x7fb8f0000be0, rs=0x7fb90511d990) at ../../../head/servers/slapd/search.c:426 #19 0x000055a09365c9fa in do_search (op=0x7fb8f0000be0, rs=0x7fb90511d990) at ../../../head/servers/slapd/search.c:267 #20 0x000055a093658e0c in connection_operation (ctx=0x7fb90511daf0, arg_v=0x7fb8f0000be0) at ../../../head/servers/slapd/connection.c:1113 #21 0x000055a09365956b in connection_read_thread (ctx=0x7fb90511daf0, argv=0x10) at ../../../head/servers/slapd/connection.c:1265 #22 0x00007fb9121feea3 in ldap_int_thread_pool_wrapper (xpool=0x55a094357ac0) at ../../../head/libraries/libldap/tpool.c:1053 #23 0x00007fb911b8c450 in start_thread (arg=0x7fb90511e640) at pthread_create.c:481 #24 0x00007fb911aaed53 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 (gdb) frame 11 #11 0x00007fb9121b8b40 in try_read1msg (ld=0x7fb8fc124d70, msgid=3, all=0, lc=0x7fb8fc128180, result=0x7fb90511c4e8) at ../../../head/libraries/libldap/result.c:680 680 refer_cnt = ldap_chase_v3referrals( ld, lr, refs, (gdb) l 675 if ( ber_scanf( &tmpber, "{v}", &refs ) == LBER_ERROR ) { 676 rc = LDAP_DECODING_ERROR; 677 678 } else { 679 /* Note: refs array is freed by ldap_chase_v3referrals */ 680 refer_cnt = ldap_chase_v3referrals( ld, lr, refs, 681 1, &lr->lr_res_error, &hadref ); 682 if ( refer_cnt > 0 ) { 683 /* successfully chased reference */ 684 /* If haven't got end search, set chasing referrals */ (gdb) p *lr $7 = {lr_msgid = 3, lr_status = 1, lr_refcnt = 1, lr_outrefcnt = 1, lr_abandoned = 0, lr_origid = 3, lr_parentcnt = 0, lr_res_msgtype = 115, lr_res_errno = 0, lr_res_error = 0x0, lr_res_matched = 0x0, lr_ber = 0x7fb8f0139eb0, lr_conn = 0x7fb8fc128180, lr_dn = {bv_len = 17, bv_val = 0x7fb8f0128b79 "dc=example,dc=com\n\001\002\n\001"}, lr_parent = 0x0, lr_child = 0x0, lr_refnext = 0x0, lr_prev = 0x0, lr_next = 0x0} (gdb) The problem appears to be due to recursion in try_read1msg() when chasing a referral. In this case it's processing msgid 3 and then while looking for response to msgid 5 it sees another response to msgid 3. It looks up the corresponding request and sees it already has a non-zero lr_refcnt and assert fails there. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

← Newer
1
...
6
7
8
9
10
11
12
...
21
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs September 2021