https://bugs.openldap.org/show_bug.cgi?id=9608
Issue ID: 9608 Summary: slapo-syncprov: Replace op on olcSpSessionlog segfault Product: OpenLDAP Version: 2.4.59 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: overlays Assignee: bugs@openldap.org Reporter: quanah@openldap.org Target Milestone: ---
With the following Syncprov overlay configuration:
dn: olcOverlay={0}syncprov,olcDatabase={2}mdb,cn=config objectClass: olcSyncProvConfig objectClass: olcOverlayConfig olcOverlay: {0}syncprov olcSpCheckpoint: 100 10
You can crash slapd with the following modification as the cn=config rootdn:
dn: olcOverlay={0}syncprov,olcDatabase={2}mdb,cn=config changetype: modify replace: olcSpSessionlog olcSpSessionlog: 10000
GDB backtrace shows:
#0 0x00007f7b43f8b954 in sp_cf_gen (c=0x7f7b0761b450) at syncprov.c:3164 on = 0x55d6fb385b90 si = 0x55d6fb35c700 rc = 0 #1 0x000055d6fa4da4ec in config_modify_internal (ca=0x7f7b0761b450, rs=<optimized out>, op=<optimized out>, ce=<optimized out>) at bconfig.c:5773 vals = 0x7f7af8002680 nvals = 0x0 d = <optimized out> e = 0x55d6fb335a38 save_attrs = 0x55d6fb349498 a = 0x55d6fb350180 i = <optimized out> dels = 0x0 rc = <optimized out> oc_at = <optimized out> ct = 0x7f7b441970e0 <spcfg+64> nocs = 3 ptr = <optimized out> s = 0x0 deltail = 0x0 ml = 0x7f7af8102cd0 #2 config_back_modify (op=<optimized out>, rs=<optimized out>) at bconfig.c:5943 cfb = <optimized out> ce = <optimized out> last = 0x55d6fb387f30 ml = <optimized out> ca = {argc = 1, argv = 0x7f7af8103610, argv_size = 513, line = 0x0, tline = 0x0, fname = 0x55d6fa5f5a91 "slapd", lineno = 0, log = "olcSpSessionlog: value #0", '\000' <repeats 4098 times>, reply = {err = 0, msg = "modify/delete: olcSpSessionlog: no such attribute", '\000' <repeats 206 times>}, depth = 0, valx = -1, values = {v_int = 10000, v_uint = 10000, v_long = 10000, v_ulong = 10000, v_ber_t = 10000, v_string = 0x2710 <Address 0x2710 out of bounds>, v_bv = {bv_len = 10000, bv_val = 0x0}, v_dn = {vdn_dn = { bv_len = 10000, bv_val = 0x0}, vdn_ndn = {bv_len = 0, bv_val = 0x0}}, v_ad = 0x2710}, rvalue_vals = 0x0, rvalue_nvals = 0x0, op = 1, type = 2, ca_op = 0x7f7af80028f0, be = 0x55d6fb35c880, bi = 0x55d6fb385b90, ca_entry = 0x55d6fb335a38, ca_private = 0x0, cleanup = 0x0, table = Cft_Overlay} rdn = {bv_len = 10, bv_val = 0x55d6fb385d70 "olcOverlay={0}syncprov,olcDatabase={2}mdb,cn=config"} ptr = <optimized out> rad = 0x55d6fb31a570 do_pause = <optimized out> #3 0x000055d6fa508b89 in fe_op_modify (op=0x7f7af80028f0, rs=0x7f7b0761d860) at modify.c:303 update = <optimized out> repl_user = <optimized out> op_be = <optimized out> bd = 0x55d6fa87da80 <slap_frontendDB> textbuf = "\006\000\000\000y\000\000\000\001\000\000\000\300\000\000\000\000\000\000\000\020\001\000\000\000\000\000\000\000\000\000\000P\215.\373\326U\000\000 \307a\a{\177\000\000\006\000\000\000\000\000\000\000u\335P\372\326U\000\000`\330a\a{\177\000\000\344l\207\372\326U\000\000\005\000\000\000\000\000\000\000 \036\000\370z\177\000\000\017\000\000\000\000\000\000\000B[\233G{\177\000\000\064\000\000\000\000\000\000\000\000_Z\004\321WbM\300\307a\a{\177", '\000' <repeats 18 times>, "\320,\020\370z\177\000\000p]5\373\326U", '\000' <repeats 18 times>, "J\227P\372\326U\000\000\200\n\000\370z\177\000\000"... #4 0x000055d6fa50ab7d in do_modify (op=0x7f7af80028f0, rs=0x7f7b0761d860) at modify.c:177 dn = {bv_len = 51, bv_val = 0x7f7af8002867 "olcOverlay={0}syncprov,olcDatabase={2}mdb,cn=config"} textbuf = "olcSpSessionlog", '\000' <repeats 240 times> tmp = 0x0 #5 0x000055d6fa4f068c in connection_operation (ctx=ctx@entry=0x7f7b0761dad0, arg_v=arg_v@entry=0x7f7af80028f0) at connection.c:1182 rc = 80 cancel = <optimized out> op = 0x7f7af80028f0 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 = 102 opidx = SLAP_OP_MODIFY conn = 0x55d6fb522120 memctx = 0x7f7af8000a80 memctx_null = 0x0 memsiz = 1048576 __PRETTY_FUNCTION__ = "connection_operation" #6 0x000055d6fa4f09fb in connection_read_thread (ctx=0x7f7b0761dad0, argv=0xb) at connection.c:1318 rc = <optimized out> cri = {op = 0x7f7af80028f0, func = 0x0, arg = 0x0, ctx = <optimized out>, nullop = <optimized out>} s = <optimized out> #7 0x00007f7b4937527a in ldap_int_thread_pool_wrapper (xpool=0x55d6fb3101d0) at tpool.c:696 pool = 0x55d6fb3101d0 task = 0x7f7b00000b40 work_list = <optimized out> ctx = {ltu_id = 140166381561600, ltu_key = {{ltk_key = 0x55d6fa4ee6a0 <conn_counter_init>, ltk_data = 0x7f7af8002710, ltk_free = 0x55d6fa4ee780 <conn_counter_destroy>}, {ltk_key = 0x55d6fa549200 <slap_sl_mem_init>, ltk_data = 0x7f7af8000a80, ltk_free = 0x55d6fa5490c0 <slap_sl_mem_destroy>}, {ltk_key = 0x55d6fa504fd0 <slap_op_free>, ltk_data = 0x0, ltk_free = 0x55d6fa504f30 <slap_op_q_destroy>}, { ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0x0} <repeats 26 times>, {ltk_key = 0x0, ltk_data = 0x7f7b484ffd61 <_L_unlock_3056+19>, ltk_free = 0x0}, { ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0x0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0x0}}} kctx = <optimized out> keyslot = <optimized out> hash = <optimized out> __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #8 0x00007f7b484feea5 in start_thread () from /lib64/libpthread.so.0 No symbol table info available. #9 0x00007f7b479bb9fd in clone () from /lib64/libc.so.6 No symbol table info available.
https://bugs.openldap.org/show_bug.cgi?id=9608
Howard Chu hyc@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |TEST Status|UNCONFIRMED |RESOLVED
--- Comment #1 from Howard Chu hyc@openldap.org --- fixed in master. bug in 2.4 and 2.5.
https://bugs.openldap.org/show_bug.cgi?id=9608
Quanah Gibson-Mount quanah@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|--- |2.5.6
--- Comment #2 from Quanah Gibson-Mount quanah@openldap.org --- master: Commits: • 0ae71baf by Howard Chu at 2021-07-13T12:10:28+01:00 ITS#9608 fix delete of nonexistent sessionlog
RE25: Commits: • 11e0c783 by Howard Chu at 2021-07-13T15:04:31+00:00 ITS#9608 fix delete of nonexistent sessionlog
RE24: Commits: • db23304b by Howard Chu at 2021-07-13T15:05:36+00:00 ITS#9608 fix delete of nonexistent sessionlog
https://bugs.openldap.org/show_bug.cgi?id=9608
Quanah Gibson-Mount quanah@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|TEST |FIXED Status|RESOLVED |VERIFIED
https://bugs.openldap.org/show_bug.cgi?id=9608
--- Comment #3 from Mehmet gelisin mehmetgelisin@aol.com --- Notice the [implicitly] tagged outer SEQUENCE. In your BER data, that additional tag seems to be missing and default tag for SEQUENCE type is used instead. http://www-look-4.com/
If you modify the original pyasn1 grammar for SearchResultEntry object to match your BER data (but not the standard!), pyasn1 decoder succeeds.
from pyasn1_modules.rfc2251 import SearchResultEntry http://www.compilatori.com/ from pyasn1.type.univ import Sequence from pyasn1.codec.ber import decoder ber = '0c\x043cn=Samba Unix UID
http://www.wearelondonmade.com/ Pool,ou=Testing,dc=stroeder,dc=de0,0\x14\x04\tuidNumber1\x07\x04\x05100050\x14\x04\tgidNumber1\x07\x04\x0510005'
SearchResultEntry.tagSet
http://www.jopspeech.com/ TagSet(Tag(tagClass=64, tagFormat=32, tagId=4)) # the following statement will invalidate SearchResultEntry grammar!
SearchResultEntry.tagSet = univ.Sequence.tagSet http://joerg.li/ SearchResultEntry.tagSet
TagSet(Tag(tagClass=0, tagFormat=32, tagId=16))
searchResultEntry, _ = decoder.decode(ber,asn1Spec=SearchResultEntry()) print searchResultEntry.prettyPrint() http://connstr.net/
SearchResultEntry: objectName='cn=Samba Unix UID Pool,ou=Testing,dc=stroeder,dc=de' attributes=PartialAttributeList: Sequence: type='uidNumber' vals=SetOf: '10005' http://embermanchester.uk/ Sequence: type='gidNumber' vals=SetOf: '10005'
Therefore my impression is that OpenLDAP yields incorrect BER data for SearchResultEntry object. What do you think?
Cheers, Ilya http://www.slipstone.co.uk/
I'd like to decode a LDAPv3 control value returned by OpenLDAP 2.4.25 when Pre-Read-Control was sent along with a LDAP modify request. But decoding it does not work.
Short example:
from pyasn1_modules.rfc2251 import SearchResultEntry from pyasn1.codec.ber import decoder ber = '0c\x043cn=Samba Unix UID
Pool,ou=Testing,dc=stroeder,dc=de0,0\x14\x04\tuidNumber1\x07\x04\x05100050\x14\x04\tgidNumber1\x07\x04\x0510005'
decoder.decode(ber,asn1Spec=SearchResultEntry())
Traceback (most recent call last): File "<stdin>", line 1, in <module> http://www.acpirateradio.co.uk/ File "/usr/local/lib/python2.6/site-packages/pyasn1-0.0.13a-py2.6.egg/pyasn1/codec/ber/decoder.py", line 663, in __call__ '%s not in asn1Spec: %s' % (tagSet, repr(asn1Spec)) pyasn1.error.PyAsn1Error: TagSet(Tag(tagClass=0, tagFormat=32, tagId=16)) not in asn1Spec: SearchResultEntry() https://waytowhatsnext.com/
Notice the [implicitly] tagged outer SEQUENCE. In your BER data, that additional tag seems to be missing and default tag for SEQUENCE type is used instead.
If you modify the original pyasn1 grammar for SearchResultEntry object to match your BER data (but not the standard!), pyasn1 decoder succeeds. https://www.webb-dev.co.uk/
from pyasn1_modules.rfc2251 import SearchResultEntry from pyasn1.type.univ import Sequence from pyasn1.codec.ber import decoder ber = '0c\x043cn=Samba Unix UID
Pool,ou=Testing,dc=stroeder,dc=de0,0\x14\x04\tuidNumber1\x07\x04\x05100050\x14\x04\tgidNumber1\x07\x04\x0510005'
SearchResultEntry.tagSet
TagSet(Tag(tagClass=64, tagFormat=32, tagId=4)) # the following statement will invalidate SearchResultEntry grammar!
SearchResultEntry.tagSet = univ.Sequence.tagSet SearchResultEntry.tagSet
TagSet(Tag(tagClass=0, tagFormat=32, tagId=16))
searchResultEntry, _ = decoder.decode(ber,asn1Spec=SearchResultEntry()) print searchResultEntry.prettyPrint()
SearchResultEntry: http://www.iu-bloomington.com/ objectName='cn=Samba Unix UID Pool,ou=Testing,dc=stroeder,dc=de' attributes=PartialAttributeList: Sequence: type='uidNumber' vals=SetOf: '10005' Sequence: type='gidNumber' vals=SetOf: '10005'
Therefore my impression is that OpenLDAP yields incorrect BER data for SearchResultEntry object. What do you think?
Cheers, Ilya
I'd like to decode a LDAPv3 control value returned by OpenLDAP 2.4.25 when Pre-Read-Control was sent along with a LDAP modify request. But decoding it does not work.
Short example:
from pyasn1_modules.rfc2251 import SearchResultEntry from pyasn1.codec.ber import decoder ber = '0c\x043cn=Samba Unix UID
Pool,ou=Testing,dc=stroeder,dc=de0,0\x14\x04\tuidNumber1\x07\x04\x05100050\x14\x04\tgidNumber1\x07\x04\x0510005'
decoder.decode(ber,asn1Spec=SearchResultEntry())
Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/usr/local/lib/python2.6/site-packages/pyasn1-0.0.13a-py2.6.egg/pyasn1/codec/ber/decoder.py", line 663, in __call__ '%s not in asn1Spec: %s' % (tagSet, repr(asn1Spec)) pyasn1.error.PyAsn1Error: TagSet(Tag(tagClass=0, tagFormat=32, tagId=16)) not in asn1Spec: SearchResultEntry()
-
openldap-its＠openldap.org