openldap-bugs

openldap-bugs@openldap.org

1 participants
21518 discussions

[Issue 6949] OpenLDAP Logging
by openldap-its＠openldap.org 25 Oct '21

25 Oct '21

https://bugs.openldap.org/show_bug.cgi?id=6949 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|TEST |FIXED -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 5344] Wrong check for bad Modify DN
by openldap-its＠openldap.org 25 Oct '21

25 Oct '21

https://bugs.openldap.org/show_bug.cgi?id=5344 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|TEST |FIXED Status|RESOLVED |VERIFIED -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[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 8775] PASSMOD exop fails with RWM and tight ACLs
by openldap-its＠openldap.org 25 Oct '21

25 Oct '21

https://bugs.openldap.org/show_bug.cgi?id=8775 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |VERIFIED Resolution|TEST |FIXED -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 6916] slapo-unique returns operations error when assertion control is used
by openldap-its＠openldap.org 25 Oct '21

25 Oct '21

https://bugs.openldap.org/show_bug.cgi?id=6916 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |VERIFIED Resolution|TEST |FIXED -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[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

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