openldap-bugs December 2020

openldap-bugs@openldap.org

3 participants
88 discussions

[Issue 9421] New: SIGSEGV in the MMR synchro
by openldap-its＠openldap.org 22 Mar '21

22 Mar '21

https://bugs.openldap.org/show_bug.cgi?id=9421 Issue ID: 9421 Summary: SIGSEGV in the MMR synchro Product: OpenLDAP Version: 2.4.56 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: benjamin.demarteau(a)liege.be Target Milestone: --- We are in the process of migrating from a single outdated node to an up to date MMR cluster. Through this process we write LSC synchronizations from the old server to the new server so we can keep the old server around. Our preliminary tests show that when LSC hammers the ldap using multiple threads while another node is included in the replication, we get segmentation faults with the following backtrace: #0 0x00007f7f578748ef in __strncasecmp_l_avx () from /lib64/libc.so.6 #1 0x000056094a7ca298 in avl_find (root=0x56094bb28820, data=data@entry=0x7f7e74000cd0, fcmp=fcmp@entry=0x56094a7166a0 <oc_index_name_cmp>) at avl.c:545 #2 0x000056094a716bde in oc_bvfind (ocname=0x7f7e74000cd0) at oc.c:186 #3 oc_bvfind (ocname=ocname@entry=0x7f7e74000cd0) at oc.c:178 #4 0x000056094a70ec5a in objectSubClassMatch (matchp=0x7f7e5fff8c8c, flags=256, syntax=<optimized out>, mr=<optimized out>, value=<optimized out>, assertedValue=0x7f7e74000cd0) at schema_prep.c:214 #5 0x000056094a6e9fb9 in ordered_value_match (match=match@entry=0x7f7e5fff8c8c, ad=0x56094bb184e0, mr=mr@entry=0x56094bb09810, flags=flags@entry=256, v1=v1@entry=0x7f7e5810f470, v2=v2@entry=0x7f7e74000cd0, text=0x7f7e5fff8c90) at value.c:693 #6 0x000056094a6ec44d in test_ava_filter (op=op@entry=0x7f7e5fff90c0, e=e@entry=0x56094bb54a88, ava=0x7f7e74000cc8, type=type@entry=163) at filterentry.c:777 #7 0x000056094a6ecfec in test_filter (op=op@entry=0x7f7e5fff90c0, e=e@entry=0x56094bb54a88, f=f@entry=0x7f7e74000d08) at filterentry.c:88 #8 0x000056094a6ecc81 in test_filter_and (flist=<optimized out>, e=0x56094bb54a88, op=0x7f7e5fff90c0) at filterentry.c:879 #9 test_filter (op=op@entry=0x7f7e5fff90c0, e=0x56094bb54a88, f=<optimized out>) at filterentry.c:118 #10 0x00007f7f5382c58f in syncprov_matchops (op=op@entry=0x7f7e5fff9c80, opc=opc@entry=0x7f7e58001808, saveit=saveit@entry=0) at syncprov.c:1393 #11 0x00007f7f5382e37f in syncprov_op_response (op=0x7f7e5fff9c80, rs=<optimized out>) at syncprov.c:2115 #12 0x000056094a6dcb98 in slap_response_play (op=op@entry=0x7f7e5fff9c80, rs=rs@entry=0x7f7e5fff9c10) at result.c:508 #13 0x000056094a6dd11c in send_ldap_response (op=op@entry=0x7f7e5fff9c80, rs=rs@entry=0x7f7e5fff9c10) at result.c:583 #14 0x000056094a6ddd43 in slap_send_ldap_result (op=0x7f7e5fff9c80, rs=0x7f7e5fff9c10) at result.c:861 #15 0x000056094a7a86fd in mdb_add (op=0x7f7e5fff9c80, rs=0x7f7e5fff9c10) at add.c:435 #16 0x000056094a73cd78 in overlay_op_walk (op=op@entry=0x7f7e5fff9c80, rs=0x7f7e5fff9c10, which=op_add, oi=0x56094bb8a720, on=<optimized out>) at backover.c:677 #17 0x000056094a73ceab in over_op_func (op=0x7f7e5fff9c80, rs=<optimized out>, which=<optimized out>) at backover.c:730 #18 0x00007f7f5361ff6a in accesslog_response (op=<optimized out>, rs=<optimized out>) at accesslog.c:1877 #19 0x000056094a6dcb98 in slap_response_play (op=op@entry=0x7f7e7410fff0, rs=rs@entry=0x7f7e5fffa870) at result.c:508 #20 0x000056094a6dd11c in send_ldap_response (op=op@entry=0x7f7e7410fff0, rs=rs@entry=0x7f7e5fffa870) at result.c:583 #21 0x000056094a6ddd43 in slap_send_ldap_result (op=0x7f7e7410fff0, rs=0x7f7e5fffa870) at result.c:861 #22 0x000056094a7a86fd in mdb_add (op=0x7f7e7410fff0, rs=0x7f7e5fffa870) at add.c:435 #23 0x000056094a73cd78 in overlay_op_walk (op=op@entry=0x7f7e7410fff0, rs=0x7f7e5fffa870, which=op_add, oi=0x56094bb8a900, on=<optimized out>) at backover.c:677 #24 0x000056094a73ceab in over_op_func (op=0x7f7e7410fff0, rs=<optimized out>, which=<optimized out>) at backover.c:730 #25 0x000056094a6d32bd in fe_op_add (op=0x7f7e7410fff0, rs=0x7f7e5fffa870) at add.c:334 #26 0x000056094a6d4139 in do_add (op=0x7f7e7410fff0, rs=0x7f7e5fffa870) at add.c:194 #27 0x000056094a6cbfc0 in connection_operation (ctx=ctx@entry=0x7f7e5fffaab0, arg_v=arg_v@entry=0x7f7e7410fff0) at connection.c:1175 #28 0x000056094a6ccdbe in connection_read_thread (ctx=0x7f7e5fffaab0, argv=0x1a) at connection.c:1311 #29 0x00007f7f5903bead in ldap_int_thread_pool_wrapper (xpool=0x56094bb2a1d0) at tpool.c:696 #30 0x00007f7f57ae414a in start_thread () from /lib64/libpthread.so.0 #31 0x00007f7f57815f23 in clone () from /lib64/libc.so.6 If we take down the second node, we cannot reproduce the segfaults anymore. Let me know if we can provide more information (we can't provide the core dump since it's full of passwords). -- You are receiving this mail because: You are on the CC list for the issue.

1 19

[Issue 9419] New: Add support for HAProxy proxy protocol v2
by openldap-its＠openldap.org 15 Mar '21

15 Mar '21

https://bugs.openldap.org/show_bug.cgi?id=9419 Issue ID: 9419 Summary: Add support for HAProxy proxy protocol v2 Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: henson(a)acm.org Target Milestone: --- Add support for the HAProxy proxy protocol v2: https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt This will allow slapd to receive and act upon client addresses when operating behind a NAT'ing load balancer or proxy server which would otherwise obscure the true client address. Patch will be submitted as a pull request on gitlab. The submitted pull request is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the pull request were developed by Paul B. Henson <henson(a)acm.org> based on specifications and example code provided by HAProxy at the above listed URL. I have not assigned rights and/or interest in this work to any party. The modifications to OpenLDAP Software are subject to the following notice: Copyright 2020 Paul B. Henson Redistribution and use in source and binary forms, with or without modification, are permitted only as authorized by the OpenLDAP Public License. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 9325] New: Expand SSL test suite for multiple EC support and SAN checks
by openldap-its＠openldap.org 10 Mar '21

10 Mar '21

https://bugs.openldap.org/show_bug.cgi?id=9325 Issue ID: 9325 Summary: Expand SSL test suite for multiple EC support and SAN checks Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- Need to expand the TLS test suite with some additional certs and EC support to ensure proper testing of issue#9054 and issue#9318 -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Bug 9199] New: Disable IPv6 makes listener work on IP address but hostname or localhost
by openldap-its＠openldap.org 02 Mar '21

02 Mar '21

https://bugs.openldap.org/show_bug.cgi?id=9199 Bug ID: 9199 Summary: Disable IPv6 makes listener work on IP address but hostname or localhost Product: OpenLDAP Version: 2.4.49 Hardware: All OS: Linux Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: st-wong(a)cuhk.edu.hk Target Milestone: --- Hi, We're compiling 2.4.49 on CentOS8. Make test fails at "test000-rootdse" with error Can't contact LDAP server. Debug log shows error "Address already in use". We're quite sure the port (9011) is not in use. Starting slapd with test command verified the error: ../servers/slapd/slapd -f testrun/slapd.1.conf -h ldap://localhost:9011 Found that it's okay to start slapd if listener URL is using IP address instead. Checked ldap_url_parse* call may not work as expected with V6 disabled (configure option --disable-ipv6). Re-do configuration and make without "--disable-ipv6" works as expected. Would you help? Thanks. -- You are receiving this mail because: You are on the CC list for the bug.

1 4

[Bug 9192] New: slapo-rwm: assert triggered with invalid UUID filter
by openldap-its＠openldap.org 02 Mar '21

02 Mar '21

https://bugs.openldap.org/show_bug.cgi?id=9192 Bug ID: 9192 Summary: slapo-rwm: assert triggered with invalid UUID filter Product: OpenLDAP Version: 2.4.48 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- slapo-rwm triggers an assert when a filter with an invalid UUID syntax is used. For example: /opt/symas/bin/ldapsearch -x -H ldaps://ldap0.example.com -D "cn=admin,dc=example,dc=com" -W -b dc=example,dc=com idmUUID=b58540b2-f16c-41c9-8147-83068004dd0a,ou=People,dc=example,dc=com Enter LDAP Password: # extended LDIF # # LDAPv3 # base <dc=example,dc=com> with scope subtree # filter: idmUUID=b58540b2-f16c-41c9-8147-83068004dd0a,ou=People,dc=example,dc=com # requesting: ALL # The above search will trigger an assert. Note that idmUUID is a custom attribute defined as: # idmUUID attributetype ( 1.3.6.1.4.1.29179.2.3.3 NAME 'idmUUID' DESC 'RFC4122 Univeral Unique Identifier for idM' EQUALITY uuidMatch SYNTAX 1.3.6.1.1.16.1 SINGLE-VALUE ) which is using the RFC4530 definition for UUID. On the slapd side, we see: #4 0x0000000000468650 in UUIDNormalize (usage=<optimized out>, syntax=<optimized out>, mr=<optimized out>, val=0x7f1c58003110, normalized=0x7f1c677fc5c0, ctx=<optimized out>) at /home/build/sold/openldap/servers/slapd/schema_init.c:3019 No locals. #5 0x00007f447599c55d in map_attr_value (dc=dc@entry=0x7f1c677fc730, adp=adp@entry=0x7f1c677fc658, mapped_attr=mapped_attr@entry=0x7f1c677fc660, value=0x7f1c58003110, mapped_value=mapped_value@entry=0x7f1c677fc670, memctx=0x7f1c58002810, remap=0) at /home/build/sold/openldap/servers/slapd/overlays/rwmmap.c:471 vtmp = {bv_len = 0, bv_val = 0x0} freeval = 0 ad = 0x1947630 mapping = 0x0 #6 0x00007f447599ccc6 in rwm_int_filter_map_rewrite (op=op@entry=0x7f1c580028f0, dc=dc@entry=0x7f1c677fc730, f=0x7f1c58003170, fstr=fstr@entry=0x7f1c677fc720) at /home/build/sold/openldap/servers/slapd/overlays/rwmmap.c:559 i = <optimized out> p = <optimized out> ad = 0x1947630 atmp = {bv_len = 7, bv_val = 0x1900bb0 "idmUUID"} vtmp = {bv_len = 139759712219536, bv_val = 0x7f1c58003240 "c"} tmp = <optimized out> ber_bvfalse = {bv_len = 18, bv_val = 0x7f447599f816 "(!(objectClass=*))"} ber_bvtf_false = {bv_len = 3, bv_val = 0x7f447599f829 "(|)"} ber_bvtrue = {bv_len = 15, bv_val = 0x7f447599f802 "(objectClass=*)"} ber_bvtf_true = {bv_len = 3, bv_val = 0x7f447599f812 "(&)"} ber_bverror = {bv_len = 9, bv_val = 0x7f447599f7f8 "(?=error)"} ber_bvunknown = {bv_len = 11, bv_val = 0x7f447599f7ec "(?=unknown)"} ber_bvnone = {bv_len = 8, bv_val = 0x7f447599f82d "(?=none)"} len = <optimized out> __PRETTY_FUNCTION__ = "rwm_int_filter_map_rewrite" #7 0x00007f447599d7a8 in rwm_filter_map_rewrite (op=op@entry=0x7f1c580028f0, dc=dc@entry=0x7f1c677fc730, f=<optimized out>, fstr=fstr@entry=0x7f1c677fc720) at /home/build/sold/openldap/servers/slapd/overlays/rwmmap.c:824 rc = <optimized out> fdc = <optimized out> ftmp = {bv_len = 26355712, bv_val = 0x7f4475224500 "\002"} #8 0x00007f4475999c5b in rwm_op_search (op=0x7f1c580028f0, rs=0x7f1c677fda60) at /home/build/sold/openldap/servers/slapd/overlays/rwm.c:976 on = 0x1922620 rwmap = 0x1922800 rc = 0 dc = {rwmap = 0x1922800, conn = 0x7f4475224500, ctx = 0x7f447599f090 "searchFilterAttrDN", rs = 0x7f1c677fda60} fstr = {bv_len = 0, bv_val = 0x0} f = 0x0 an = 0x0 text = 0x0 roc = 0x7f1c58003218 #9 0x000000000049776a in overlay_op_walk (op=op@entry=0x7f1c580028f0, rs=rs@entry=0x7f1c677fda60, which=which@entry=op_search, oi=oi@entry=0x1924430, on=0x1922620) at /home/build/sold/openldap/servers/slapd/backover.c:671 func = 0x1922678 rc = 32768 #10 0x00000000004978be in over_op_func (op=0x7f1c580028f0, rs=0x7f1c677fda60, which=op_search) at /home/build/sold/openldap/servers/slapd/backover.c:747 oi = 0x1924430 on = <optimized out> be = 0x728420 <slap_frontendDB> db = {bd_info = 0x1922620, bd_self = 0x728420 <slap_frontendDB>, be_ctrls = "\000", '\001' <repeats 17 times>, '\000' <repeats 14 times>, be_flags = 768, 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 = 0x18cb690, be_nsuffix = 0x18cb6e0, be_schemadn = {bv_len = 12, bv_val = 0x1955c20 "cn=Subschema"}, be_schemandn = {bv_len = 12, bv_val = 0x1955370 "cn=subschema"}, be_rootdn = { bv_len = 0, bv_val = 0x0}, be_rootndn = {bv_len = 0, bv_val = 0x0}, be_rootpw = {bv_len = 0, bv_val = 0x0}, be_max_deref_depth = 0, be_def_limit = {lms_t_soft = 3600, lms_t_hard = 0, lms_s_soft = 50, 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 = 0x1925890, 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 = 0x0, 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 = 0x7200e8 <cf_ocs+392>, be_private = 0x0, be_next = {stqe_next = 0x18cbcc0}} sc = <optimized out> cb = 0x7f1c580031e8 rc = 32768 __PRETTY_FUNCTION__ = "over_op_func" #11 0x0000000000431006 in do_search (op=0x7f1c580028f0, rs=0x7f1c677fda60) at /home/build/sold/openldap/servers/slapd/search.c:247 base = {bv_len = 14, bv_val = 0x7f1c580025c7 "dc=example,dc=com"} siz = 0 off = 0 i = <optimized out> #12 0x000000000042ede5 in connection_operation (ctx=ctx@entry=0x7f1c677fdbd0, arg_v=arg_v@entry=0x7f1c580028f0) at /home/build/sold/openldap/servers/slapd/connection.c:1167 rc = 80 cancel = <optimized out> op = 0x7f1c580028f0 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 = 0x7f4475224500 memctx = 0x7f1c58002810 memctx_null = 0x0 memsiz = 1048576 __PRETTY_FUNCTION__ = "connection_operation" #13 0x000000000042f0ea in connection_read_thread (ctx=0x7f1c677fdbd0, argv=0x16) at /home/build/sold/openldap/servers/slapd/connection.c:1314 rc = <optimized out> cri = {op = 0x7f1c580028f0, func = 0x0, arg = 0x0, ctx = <optimized out>, nullop = <optimized out>} s = <optimized out> #14 0x00007f447a585353 in ldap_int_thread_pool_wrapper (xpool=0x18b1340) at /home/build/sold/openldap/libraries/libldap_r/tpool.c:963 pq = 0x18b1340 pool = 0x18b1250 task = 0x7f1c68000da0 work_list = <optimized out> ctx = {ltu_pq = 0x18b1340, ltu_id = 139759972247296, ltu_key = {{ltk_key = 0x42cbf0 <conn_counter_init>, ltk_data = 0x7f1c58002700, ltk_free = 0x42ccb0 <conn_counter_destroy>}, { ltk_key = 0x47fef0 <slap_sl_mem_init>, ltk_data = 0x7f1c58002810, ltk_free = 0x47fdb0 <slap_sl_mem_destroy>}, {ltk_key = 0x1ae4a40, ltk_data = 0x7f1c58102f30, ltk_free = 0x7f44763ff550 <mdb_reader_free>}, {ltk_key = 0x4416f0 <slap_op_free>, ltk_data = 0x0, ltk_free = 0x441650 <slap_op_q_destroy>}, {ltk_key = 0x0, ltk_data = 0x7f1c58000a80, ltk_free = 0x0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0x0} <repeats 27 times>}} kctx = <optimized out> keyslot = <optimized out> hash = <optimized out> pool_lock = 0 freeme = 0 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #15 0x00007f4478d42ea5 in start_thread () from /lib64/libpthread.so.0 No symbol table info available. #16 0x00007f4478a6b8cd in clone () from /lib64/libc.so.6 No symbol table info available. (gdb) -- You are receiving this mail because: You are on the CC list for the bug.

1 4

[Issue 9422] New: add #define LDAP_OPT_X_TLS_PROTOCOL_TLS1_3 to ldap.h
by openldap-its＠openldap.org 26 Feb '21

26 Feb '21

https://bugs.openldap.org/show_bug.cgi?id=9422 Issue ID: 9422 Summary: add #define LDAP_OPT_X_TLS_PROTOCOL_TLS1_3 to ldap.h Product: OpenLDAP Version: 2.4.56 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: michael(a)stroeder.com Target Milestone: --- I'm not sure whether naively adding this line to ldap.h would be correct: #define LDAP_OPT_X_TLS_PROTOCOL_TLS1_3 ((3 << 8) + 4) -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Bug 9197] New: slapd-ldap/slapo-chain hits error 80 after idletimeout
by openldap-its＠openldap.org 26 Feb '21

26 Feb '21

https://bugs.openldap.org/show_bug.cgi?id=9197 Bug ID: 9197 Summary: slapd-ldap/slapo-chain hits error 80 after idletimeout Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- From a customer: In order to communicate via the LB managed writable ldap, we have to ensure that an idle connection is periodically refreshed. If we do not, the LB will silently drop the connection after 5 minutes. Therefore to combat that I set an olcIdleTimeout on the writable server so that the chain cached connections will be removed before the LB timeout hits. However the slapo-ldap client goes into CLOSE_WAIT state, which causes subsequent ldapmodify updates being brokered by the read only instance to fail with err=80. There appear to be a few bugs filed on this in the past against slapd-ldap, but it's not clear if we may be hitting the same issue, or if this is a new one. I've also connected the read only instances directly to the writable ldap instances and the CLOSE_WAIT issue persists, so I don't believe the CLOSE_WAIT issue is caused by the LB These were the other threads I found as I started looking for this problem, these are using the ldap-proxy though I think: https://www.openldap.org/lists/openldap-technical/201301/msg00323.html http://www.openldap.org/lists/openldap-software/201004/msg00060.html https://www.openldap.org/lists/openldap-bugs/200412/msg00029.html The LB we have seems to be set to forget connections that last over 5 min per the setting, so the 240:10:30 seemed like it should have worked and I just thought it wasn't working because in the man page the text "Only some systems support the customization of these values" is present. however after setting keepalive to 60:10:30 did I maintain a stable connection, so there may be other network settings at play I'm not aware of. -- You are receiving this mail because: You are on the CC list for the bug.

1 14

[Issue 9292] New: Man page for LDAP_OPT_TIMEOUT/LDAP_OPT_NETWORK_TIMEOUT unclear on use of free
by openldap-its＠openldap.org 26 Feb '21

26 Feb '21

https://bugs.openldap.org/show_bug.cgi?id=9292 Issue ID: 9292 Summary: Man page for LDAP_OPT_TIMEOUT/LDAP_OPT_NETWORK_TIMEOUT unclear on use of free Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: sshanks(a)kx.com Target Milestone: --- Ref: https://git.openldap.org/openldap/openldap/-/blob/master/doc/man/man3/ldap_… https://www.openldap.org/software/man.cgi?query=ldap_get_option&sektion=3&a… See details of LDAP_OPT_TIMEOUT and LDAP_OPT_NETWORK_TIMEOUT. Both state "the caller has to free *outvalue" This can be interpreted as the called must call free on outvalue. This can cause a random crash when 'free' used (build on Linux ran ok, Windows crashed immediately) Would be better is it stated that the caller must use 'ldap_memfree', in the same way as other options state use must use 'ldap_memfree'. FYI: within the code, get_option for these params calls ldap_int_timeval_dup which calls LDAP_MALLOC -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Bug 9238] New: access control documentation is confusing
by openldap-its＠openldap.org 26 Feb '21

26 Feb '21

https://bugs.openldap.org/show_bug.cgi?id=9238 Bug ID: 9238 Summary: access control documentation is confusing Product: OpenLDAP Version: unspecified 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 716 --> https://bugs.openldap.org/attachment.cgi?id=716&action=edit git format-patch output slapd.access says "Access control checking stops at the first match of the <what> and <who> clause, unless otherwise dictated by the <control> clause." But this, by itself, is wrong. You have to read the next sentence, which says there's an implicit "by * none stop", meaning that the default is to stop when only <what> matches. Patch attached. 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 16

[Bug 9246] New: Improve authzFrom/authzTo docs
by openldap-its＠openldap.org 26 Feb '21

26 Feb '21

https://bugs.openldap.org/show_bug.cgi?id=9246 Bug ID: 9246 Summary: Improve authzFrom/authzTo docs Product: OpenLDAP Version: unspecified 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 724 --> https://bugs.openldap.org/attachment.cgi?id=724&action=edit Patch The defaults for group/objectclass/attributetype were not documented. Improve the section overall. 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 9

← Newer
1
2
3
4
5
6
7
8
9
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs December 2020