openldap-bugs April 2020

openldap-bugs@openldap.org

2 participants
338 discussions

[Bug 9121] dynlist enhancements
by openldap-its＠openldap.org 07 Apr '20

07 Apr '20

https://bugs.openldap.org/show_bug.cgi?id=9121 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|TEST |--- Status|RESOLVED |CONFIRMED --- Comment #3 from Quanah Gibson-Mount <quanah(a)openldap.org> --- Current code periodically triggers a SEGV in test044: (gdb) cont Continuing. [New Thread 0x7fd9d2ce2700 (LWP 18294)] [New Thread 0x7fd9d24e1700 (LWP 18295)] Thread 3 "lt-slapd" received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fd9d2ce2700 (LWP 18294)] 0x00007fd9d42a697c in comp_candidates (op=0x7fd9c4002900, rtxn=0x7fd9c410ad10, mra=0x7fd9c4005430, f=0x1c, ids=0x7fd9d0c5f018, tmp=0x7fd9d095f018, stack=0x7fd9d0d5f018) at filterindex.c:464 464 filterindex.c: No such file or directory. #0 0x00007fd9d42a697c in comp_candidates (op=0x7fd9c4002900, rtxn=0x7fd9c410ad10, mra=0x7fd9c4005430, f=0x1c, ids=0x7fd9d0c5f018, tmp=0x7fd9d095f018, stack=0x7fd9d0d5f018) at filterindex.c:464 rc = 1409434333 #1 0x00007fd9d42a6bb2 in ext_candidates (op=0x7fd9c4002900, rtxn=0x7fd9c410ad10, mra=0x7fd9c4005430, ids=0x7fd9d0c5f018, tmp=0x7fd9d095f018, stack=0x7fd9d0d5f018) at filterindex.c:507 No locals. #2 0x00007fd9d42a5c0f in mdb_filter_candidates (op=0x7fd9c4002900, rtxn=0x7fd9c410ad10, f=0x7fd9c4005410, ids=0x7fd9d0c5f018, tmp=0x7fd9d095f018, stack=0x7fd9d0d5f018) at filterindex.c:206 rc = 0 aa = 0x7fd9c40016c0 #3 0x00007fd9d42a6ee5 in list_candidates (op=0x7fd9c4002900, rtxn=0x7fd9c410ad10, flist=0x7fd9c4005410, ftype=160, ids=0x7fd9d0b5f018, tmp=0x7fd9d095f018, save=0x7fd9d0c5f018) at filterindex.c:582 rc = 0 f = 0x7fd9c4005410 #4 0x00007fd9d42a5ae1 in mdb_filter_candidates (op=0x7fd9c4002900, rtxn=0x7fd9c410ad10, f=0x7fd9c4003b40, ids=0x7fd9d0b5f018, tmp=0x7fd9d095f018, stack=0x7fd9d0c5f018) at filterindex.c:195 rc = 0 aa = 0x7fd9d2cd0190 #5 0x00007fd9d42a6ee5 in list_candidates (op=0x7fd9c4002900, rtxn=0x7fd9c410ad10, flist=0x7fd9c4003b40, ftype=160, ids=0x7fd9d0a5f018, tmp=0x7fd9d095f018, save=0x7fd9d0b5f018) at filterindex.c:582 rc = 0 f = 0x7fd9c4003b40 #6 0x00007fd9d42a5ae1 in mdb_filter_candidates (op=0x7fd9c4002900, rtxn=0x7fd9c410ad10, f=0x7fd9c4003b20, ids=0x7fd9d0a5f018, tmp=0x7fd9d095f018, stack=0x7fd9d0b5f018) at filterindex.c:195 rc = 0 aa = 0x0 #7 0x00007fd9d42a6ee5 in list_candidates (op=0x7fd9c4002900, rtxn=0x7fd9c410ad10, flist=0x7fd9d2cd0390, ftype=161, ids=0x7fd9d07df018, tmp=0x7fd9d095f018, save=0x7fd9d0a5f018) at filterindex.c:582 rc = 0 f = 0x7fd9c4003b20 #8 0x00007fd9d42a5b7c in mdb_filter_candidates (op=0x7fd9c4002900, rtxn=0x7fd9c410ad10, f=0x7fd9d2cd03b0, ids=0x7fd9d07df018, tmp=0x7fd9d095f018, stack=0x7fd9d0a5f018) at filterindex.c:201 rc = 0 aa = 0x0 #9 0x00007fd9d42a10e7 in search_candidates (op=0x7fd9c4002900, rs=0x7fd9d2ce1a70, e=0x7fd9c4005578, isc=0x7fd9d2cd0670, mci=0x7fd9c4001530, ids=0x7fd9d07df018, stack=0x7fd9d095f018) at search.c:1411 mdb = 0x7fd9d418c010 rc = 0 depth = 4 f = 0x7fd9d2cd03b0 rf = {f_choice = 163, f_un = {f_un_result = -758316016, f_un_desc = 0x7fd9d2cd0410, f_un_ava = 0x7fd9d2cd0410, f_un_ssa = 0x7fd9d2cd0410, f_un_mra = 0x7fd9d2cd0410, f_un_complex = 0x7fd9d2cd0410}, f_next = 0x7fd9c4003b20} xf = {f_choice = 161, f_un = {f_un_result = -758316144, f_un_desc = 0x7fd9d2cd0390, f_un_ava = 0x7fd9d2cd0390, f_un_ssa = 0x7fd9d2cd0390, f_un_mra = 0x7fd9d2cd0390, f_un_complex = 0x7fd9d2cd0390}, f_next = 0x0} nf = {f_choice = 140573521282144, f_un = {f_un_result = -758315808, f_un_desc = 0x7fd9d2cd04e0, f_un_ava = 0x7fd9d2cd04e0, f_un_ssa = 0x7fd9d2cd04e0, f_un_mra = 0x7fd9d2cd04e0, f_un_complex = 0x7fd9d2cd04e0}, f_next = 0x0} sf = {f_choice = 8, f_un = {f_un_result = -735244463, f_un_desc = 0x7fd9d42d0f51, f_un_ava = 0x7fd9d42d0f51, f_un_ssa = 0x7fd9d42d0f51, f_un_mra = 0x7fd9d42d0f51, f_un_complex = 0x7fd9d42d0f51}, f_next = 0x7fd9c4005578} aa_ref = {aa_desc = 0x55ebd3472230, aa_value = {bv_len = 8, bv_val = 0x7fd9d42d0f51 "referral"}, aa_cf = 0x0} aa_subentry = {aa_desc = 0x0, aa_value = {bv_len = 0, bv_val = 0x0}, aa_cf = 0x0} #10 0x00007fd9d429e856 in mdb_search (op=0x7fd9c4002900, rs=0x7fd9d2ce1a70) at search.c:677 mdb = 0x7fd9d418c010 id = 18446744073709551615 cursor = 2 nsubs = 13 ncand = 1 cscope = 94471351201400 lastid = 18446744073709551615 candidates = 0x7fd9d07df018 iscopes = 0x7fd9d08df018 c0 = 0x7fd9d07df018 scopes = 0x7fd9d19e0010 stack = 0x7fd9d095f018 e = 0x0 base = 0x7fd9c4005578 matched = 0x0 attrs = 0x7fd9c4003a38 mask = 4159 stoptime = 1586274302 manageDSAit = 0 tentries = 0 isc = <error reading variable isc (value of type `IdScopes' requires 65592 bytes, which is more than max-value-size)> mci = 0x7fd9c4001530 mcd = 0x7fd9c4000d20 wwctx = {txn = 0x7fd9c410ad10, mcd = 0x0, key = 140573521282720, data = {mv_size = 140573544266088, mv_data = 0x8d2cd06f0}, flag = 0, nentries = 1} cb = {sc_next = 0x0, sc_response = 0x0, sc_cleanup = 0x0, sc_private = 0x0, sc_writewait = 0x0} opinfo = {moi_oe = {oe_next = {sle_next = 0x0}, oe_key = 0x7fd9d418c010}, moi_txn = 0x7fd9c410ad10, moi_ref = 1, moi_flag = 1 '\001'} moi = 0x7fd9d2cd05c0 ltid = 0x7fd9c410ad10 #11 0x000055ebd3064d9c in overlay_op_walk (op=0x7fd9c4002900, rs=0x7fd9d2ce1a70, which=op_search, oi=0x55ebd34b9f50, on=0x0) at backover.c:706 bi = 0x7fd9d42da1a0 <bi> rc = 32768 #12 0x000055ebd3065055 in over_op_func (op=0x7fd9c4002900, rs=0x7fd9d2ce1a70, which=op_search) at backover.c:766 oi = 0x55ebd34b9f50 on = 0x55ebd34f9b00 be = 0x55ebd34f76f0 db = {bd_info = 0x7fd9d42da1a0 <bi>, bd_self = 0x55ebd34f76f0, be_ctrls = "\000\001\001\001\000\001\000\000\001\000\000\001\001\000\001\001", '\000' <repeats 16 times>, "\001", be_flags = 2312, be_restrictops = 0, be_requires = 0, be_ssf_set = {sss_ssf = 0, sss_transport = 0, sss_tls = 0, sss_sasl = 0, sss_update_ssf = 0, sss_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 0}, be_suffix = 0x55ebd34f98b0, be_nsuffix = 0x55ebd34f98e0, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_schemandn = { bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 28, bv_val = 0x55ebd34f9980 "cn=Manager,dc=example,dc=com"}, be_rootndn = {bv_len = 28, bv_val = 0x55ebd34f99d0 "cn=manager,dc=example,dc=com"}, be_rootpw = {bv_len = 6, bv_val = 0x55ebd34f9810 "secret"}, be_max_deref_depth = 15, be_def_limit = { lms_t_soft = 3600, lms_t_hard = 0, lms_s_soft = 500, lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x0, be_acl = 0x7fd9c810d2f0, be_dfltaccess = ACL_READ, be_extra_anlist = 0x0, be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x0, be_pending_csn_list = 0x55ebd35ae4e0, be_pcl_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __elision = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, be_syncinfo = 0x0, be_pb = 0x0, be_cf_ocs = 0x7fd9d42d9e20 <mdbocs+64>, be_private = 0x7fd9d418c010, be_next = {stqe_next = 0x0}} sc = 0x55ebd34f9b00 cb = 0x7fd9c4003a90 rc = 32768 __PRETTY_FUNCTION__ = "over_op_func" #13 0x000055ebd30651cd in over_op_search (op=0x7fd9c4002900, rs=0x7fd9d2ce1a70) at backover.c:796 No locals. #14 0x000055ebd2fc6aaa in fe_op_search (op=0x7fd9c4002900, rs=0x7fd9d2ce1a70) at search.c:406 bd = 0x55ebd30fc680 <slap_frontendDB> #15 0x000055ebd2fc6294 in do_search (op=0x7fd9c4002900, rs=0x7fd9d2ce1a70) at search.c:247 base = {bv_len = 27, bv_val = 0x7fd9c428fe98 "ou=People,dc=example,dc=com"} siz = 1 off = 0 i = 1 #16 0x000055ebd2fc280f in connection_operation (ctx=0x7fd9d2ce1bd0, arg_v=0x7fd9c4002900) at connection.c:1174 rc = 80 cancel = 32729 op = 0x7fd9c4002900 rs = {sr_type = REP_RESULT, sr_tag = 0, sr_msgid = 0, sr_err = 0, sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0, sr_ctrls = 0x0, sr_un = {sru_search = { r_entry = 0x0, r_attr_flags = 0, r_operational_attrs = 0x0, r_attrs = 0x0, r_nentries = 0, r_v2ref = 0x0}, sru_sasl = {r_sasldata = 0x0}, sru_extended = { r_rspoid = 0x0, r_rspdata = 0x0}}, sr_flags = 0} tag = 99 opidx = SLAP_OP_SEARCH conn = 0x7fd9d40e8ed0 memctx = 0x7fd9c4002e70 memctx_null = 0x0 memsiz = 1048576 __PRETTY_FUNCTION__ = "connection_operation" #17 0x000055ebd2fc2f2f in connection_read_thread (ctx=0x7fd9d2ce1bd0, argv=0xc) at connection.c:1325 rc = 0 cri = {op = 0x7fd9c4002900, func = 0x0, arg = 0x0, ctx = 0x7fd9d2ce1bd0, nullop = 0} s = 12 #18 0x00007fd9d4d1d3ea in ldap_int_thread_pool_wrapper (xpool=0x55ebd34a1040) at tpool.c:1048 pq = 0x55ebd34a1040 pool = 0x55ebd34a0f30 task = 0x7fd9cc000b20 work_list = 0x55ebd34a10b0 ctx = {ltu_pq = 0x55ebd34a1040, ltu_id = 140573521356544, ltu_key = {{ltk_key = 0x55ebd2fc1f1f <conn_counter_init>, ltk_data = 0x7fd9c4002d60, ltk_free = 0x55ebd2fc1d34 <conn_counter_destroy>}, {ltk_key = 0x55ebd303f0f0 <slap_sl_mem_init>, ltk_data = 0x7fd9c4002e70, ltk_free = 0x55ebd303ef07 <slap_sl_mem_destroy>}, {ltk_key = 0x55ebd2fde919 <slap_op_free>, ltk_data = 0x0, ltk_free = 0x55ebd2fde86a <slap_op_q_destroy>}, { ltk_key = 0x55ebd35ae500, ltk_data = 0x7fd9c410ad10, ltk_free = 0x7fd9d42ae3e9 <mdb_reader_free>}, {ltk_key = 0x7fd9d42a0ad8 <search_stack>, ltk_data = 0x7fd9d07df010, ltk_free = 0x7fd9d42a0ab4 <search_stack_free>}, {ltk_key = 0x7fd9d429d288 <scope_chunk_get>, ltk_data = 0x7fd9d04de010, ltk_free = 0x7fd9d429d23f <scope_chunk_free>}, {ltk_key = 0x0, ltk_data = 0x7fd9c8000cd0, ltk_free = 0x0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0x0} <repeats 25 times>}} kctx = 0x0 i = 32 keyslot = 831 hash = 391062335 pool_lock = 0 freeme = 0 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #19 0x00007fd9d497efa3 in start_thread (arg=<optimized out>) at pthread_create.c:486 ret = <optimized out> pd = <optimized out> now = <optimized out> unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140573521356544, 516393886524641449, 140573529738174, 140573529738175, 140573521356544, 0, -533328986613477207, -533341552069701463}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}} not_first_call = <optimized out> #20 0x00007fd9d444b4cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 No locals. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 8245] slapo-unique constraints bypassed by manageDsaIt, change to relax?
by openldap-its＠openldap.org 07 Apr '20

07 Apr '20

1 0

[Bug 8245] slapo-unique constraints bypassed by manageDsaIt, change to relax?
by openldap-its＠openldap.org 07 Apr '20

07 Apr '20

https://bugs.openldap.org/show_bug.cgi?id=8245 --- Comment #14 from Quanah Gibson-Mount <quanah(a)openldap.org> --- Commits: • 6d6a3300 by Ondřej Kuzník at 2020-04-06T20:44:09+00:00 ITS#8245 Use Relax control to avoid uniqueness checks Still needs to retrieve the entry for ACL resolution until we can restrict controls with ACLs -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 8528] Incorrect results on replace op for olcAccess
by openldap-its＠openldap.org 06 Apr '20

06 Apr '20

https://bugs.openldap.org/show_bug.cgi?id=8528 --- Comment #6 from Quanah Gibson-Mount <quanah(a)openldap.org> --- (In reply to Ondřej Kuzník from comment #5) > On Thu, Apr 02, 2020 at 04:59:46PM +0000, openldap-its(a)openldap.org wrote: > >> Not saying it's a bad idea, but the interactions with a delete mod might be > >> a little confusing: > > > > Well, that's why I limited the scope of this bug purely to replace ops where > > the entire structure is getting replaced. For add/delete, it must not re-order > > anything. > > Not so sure about that, my thinking is a replace: attr should be equal to > > delete: attr > - > add: attr > replaced values > > And you're now saying that's not the case anymore. Actually I was agreeing with you. ;) Like in this example: changetype: modify delete: olcAccess olcAccess: {2} olcAccess: {1} olcAccess: {0} It would be a disaster to re-order things, and the correct thing to do is what you proposed, which is to break them down into individual changes like: changetype: modify delete: olcAccess olcAccess: {2} - delete: olcAccess olcAccess: {1} - delete: olcAccess olcAccess: {0} I.e., reordering it to 0/1/2 would be very bad. ;) -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 7420] Way to bypass overlay unique and constranit
by openldap-its＠openldap.org 06 Apr '20

06 Apr '20

https://bugs.openldap.org/show_bug.cgi?id=7420 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |CONFIRMED Ever confirmed|0 |1 Keywords| |OL_2_5_REQ -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 5705] [enhancement] slapo-constraint could honor "relax" by not checking for constraints
by openldap-its＠openldap.org 06 Apr '20

06 Apr '20

https://bugs.openldap.org/show_bug.cgi?id=5705 Ryan Tandy <ryan(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.openldap.org/s | |how_bug.cgi?id=9204 -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 8245] slapo-unique constraints bypassed by manageDsaIt, change to relax?
by openldap-its＠openldap.org 06 Apr '20

06 Apr '20

https://bugs.openldap.org/show_bug.cgi?id=8245 Ryan Tandy <ryan(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.openldap.org/s | |how_bug.cgi?id=9204 -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 7084] Password Modify Extended Operation to set pwdReset: TRUE
by openldap-its＠openldap.org 06 Apr '20

06 Apr '20

https://bugs.openldap.org/show_bug.cgi?id=7084 --- Comment #3 from Michael Ströder <michael(a)stroeder.com> --- Maybe my original comment was not clear enough. Of course it is sufficient for most use-cases to just check authz-DN != entryDN. My suggestion was to define a new attribute for a pwdPolicy entry for defining authz-IDs considered to be an administrator - kind of an additional constraint to the condition above. The syntax could be similar or the same to that already implemented for authzTo/authzFrom attributes. But no proxy authorization allowed at all. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 7596] slapo-ppolicy: OpenLDAP returning incorrect value for "graceAuthNsRemaining"
by openldap-its＠openldap.org 06 Apr '20

06 Apr '20

https://bugs.openldap.org/show_bug.cgi?id=7596 --- Comment #2 from Ondřej Kuzník <ondra(a)mistotebe.net> --- I'm not 100% sure that's the wrong number to return (according to the spec) as we should return "the number of values in that attribute subtracted from the value of pwdGraceAuthNLimit" and the number of values is one lower that you would expect while we're still processing the bind. Might be worth changing the message in the client to reflect that? -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 7084] Password Modify Extended Operation to set pwdReset: TRUE
by openldap-its＠openldap.org 06 Apr '20

06 Apr '20

https://bugs.openldap.org/show_bug.cgi?id=7084 --- Comment #2 from Ondřej Kuzník <ondra(a)mistotebe.net> --- How about deciding whether this is an administrator by checking whether the authorization identity is the same as the entry DN? For those, we can add pwdReset to the modify unless already specified. The concern is there might be management frontends that use a common identity for their LDAP requests and don't do ProxyAuthZ, do we just force them to do the right thing now? -- You are receiving this mail because: You are on the CC list for the bug.

1 0

← Newer
1
...
25
26
27
28
29
30
31
...
34
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs April 2020