openldap-bugs

openldap-bugs@openldap.org

1 participants
20964 discussions

(ITS#6507) backglue and paged results issue
by masarati＠aero.polimi.it 06 Apr '10

06 Apr '10

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (129.72.141.24) Submitted by: ando When requesting paged results control on glued databases, if a database (either superior or subordinate) returns one page that ends with the last corresponding entry in that database, the resulting cookie is empty. Thus, the result returned to the client corresponds to the final result of a paged response. However, other databases may have returned data. A fix is being designed. p.

1 0

Re: (ITS#6506) Use of back-perl in slapd.conf in subordinate database causes slapcat to segfault
by mark.cave-ayland＠siriusit.co.uk 06 Apr '10

06 Apr '10

masarati(a)aero.polimi.it wrote: > OK, I've found the problem, and it seems to be a configuration problem. > Please read below. Great. Thanks for taking the time to look at this. > ^^^ An entry with the same DN exists in the superior database. As a > consequence, this entry is returned by back-bdb's tool functions, but > backglue tries to release it using back-perl. Since back-perl does not > have any tool functions, what is considered a safe replacement is used. > Unfortunately, the safe replacement doesn't know how to deal with > read-only entries returned by back-bdb. The solution consists in: > > - temporarily commenting the instance of back-perl > > - removing this entry from your back-bdb > > - re-enabling the instance of back-perl > > A follow-on to this ITS could be to devise a means to detect whether a > superior database contains entries that belong to a subordinate one, and > warn the administrator of the inconsistency. Ah I see. I remember thinking at the time whether or not I needed a DN within my master database too (similar to a FS mount point) but obviously it has been this that has been causing the problem. At least now I know that this isn't the case and can work around it. I'd expect a subordinate database to always override the master (similar to the mount point idea again) but in the case of slapcat then I believe it should probably just ignore a subordinate that doesn't have a physical backing store presence such as back-perl. I'm not sure quite how you'd mark this though. An appropriately worded warning would definitely be a good start, especially as when I first started working with back-perl as a subordinate, I was confused that putting the subordinate definition after the master would always fail whereas putting it before would allow it to work. ATB, Mark. -- Mark Cave-Ayland - Senior Technical Architect PostgreSQL - PostGIS Sirius Corporation plc - control through freedom http://www.siriusit.co.uk t: +44 870 608 0063 Sirius Labs: http://www.siriusit.co.uk/labs

1 0

Re: (ITS#6506) Use of back-perl in slapd.conf in subordinate database causes slapcat to segfault
by masarati＠aero.polimi.it 06 Apr '10

06 Apr '10

OK, I've found the problem, and it seems to be a configuration problem. Please read below. > Here is the slapd.conf used in the test: > > > # > # See slapd.conf(5) for details on configuration options. > # This file should NOT be world readable. > # > include /home/build/rel-openldap/etc/openldap/schema/core.schema > > # Define global ACLs to disable default read access. > > # Do not enable referrals until AFTER you have a working directory > # service AND an understanding of referrals. > #referral ldap://root.openldap.org > > pidfile /home/build/rel-openldap/var/run/slapd.pid > argsfile /home/build/rel-openldap/var/run/slapd.args > > # Load dynamic backend modules: > # modulepath /home/build/rel-openldap/libexec/openldap > # moduleload back_bdb.la > # moduleload back_hdb.la > # moduleload back_ldap.la > > # Sample security restrictions > # Require integrity protection (prevent hijacking) > # Require 112-bit (3DES or better) encryption for updates > # Require 63-bit encryption for simple bind > # security ssf=1 update_ssf=112 simple_bind=64 > > # Sample access control policy: > # Root DSE: allow anyone to read it > # Subschema (sub)entry DSE: allow anyone to read it > # Other DSEs: > # Allow self write access > # Allow authenticated users read access > # Allow anonymous users to authenticate > # Directives needed to implement policy: > # access to dn.base="" by * read > # access to dn.base="cn=Subschema" by * read > # access to * > # by self write > # by users read > # by anonymous auth > # > # if no access controls are present, the default policy > # allows anyone and everyone to read anything but restricts > # updates to rootdn. (e.g., "access to * by * read") > # > # rootdn can always read and write EVERYTHING! > > database perl > suffix "ou=perl,dc=my-domain,dc=com" ^^ This is the suffix where the instance of back-perl is rooted at > subordinate > perlModulePath /home/build/rel-openldap/etc/openldap > perlModule SampleLDAP > > ####################################################################### > # BDB database definitions > ####################################################################### > > database bdb > suffix "dc=my-domain,dc=com" > rootdn "cn=Manager,dc=my-domain,dc=com" > # Cleartext passwords, especially for the rootdn, should > # be avoid. See slappasswd(8) and slapd.conf(5) for details. > # Use of strong authentication encouraged. > rootpw secret > # The database directory MUST exist prior to running slapd AND > # should only be accessible by the slapd and slap tools. > # Mode 700 recommended. > directory /home/build/rel-openldap/var/openldap-data > # Indices to maintain > index objectClass eq > > > And here is the slapcat output when the perl database is disabled in > slapd.conf to prevent the crash: > > > dn: dc=my-domain,dc=com > objectClass: top > objectClass: dcObject > objectClass: organization > o:: bXlkb21haW4uY29tIA== > dc: my-domain > structuralObjectClass: organization > entryUUID: 0bdc2650-d5c0-102e-9fe7-3350c645132d > creatorsName: cn=Manager,dc=my-domain,dc=com > createTimestamp: 20100406120241Z > entryCSN: 20100406120241.310422Z#000000#000#000000 > modifiersName: cn=Manager,dc=my-domain,dc=com > modifyTimestamp: 20100406120241Z > > dn: ou=real,dc=my-domain,dc=com > objectClass: organizationalUnit > objectClass: top > structuralObjectClass: organizationalUnit > entryUUID: 5644fb04-d5c0-102e-9c04-81e0ba1bb1f2 > creatorsName: cn=Manager,dc=my-domain,dc=com > createTimestamp: 20100406120446Z > ou: real > entryCSN: 20100406120458.545769Z#000000#000#000000 > modifiersName: cn=Manager,dc=my-domain,dc=com > modifyTimestamp: 20100406120458Z > > dn: ou=perl,dc=my-domain,dc=com ^^^ An entry with the same DN exists in the superior database. As a consequence, this entry is returned by back-bdb's tool functions, but backglue tries to release it using back-perl. Since back-perl does not have any tool functions, what is considered a safe replacement is used. Unfortunately, the safe replacement doesn't know how to deal with read-only entries returned by back-bdb. The solution consists in: - temporarily commenting the instance of back-perl - removing this entry from your back-bdb - re-enabling the instance of back-perl A follow-on to this ITS could be to devise a means to detect whether a superior database contains entries that belong to a subordinate one, and warn the administrator of the inconsistency. p.

1 0

Re: (ITS#6506) Use of back-perl in slapd.conf in subordinate database causes slapcat to segfault
by masarati＠aero.polimi.it 06 Apr '10

06 Apr '10

> masarati(a)aero.polimi.it wrote: > >>> *** glibc detected *** ./sbin/slapcat: free(): invalid pointer: >> >> ^^^ this message is not quite informative, nor is what follows below. >> Please read <http://www.openldap.org/faq/data/cache/56.html> carefully, >> and provide the information required. >> >> p. > > Okay. I figured it was easy enough to recreate that I wouldn't need to > build a full debug build myself, but looks like I need to do that > anyway. Also, what is the best way to not get "strip" to be > automatically invoked during "make install"? I ended up temporarily > removing the binary just to get unstripped versions. What about make STRIP="" install ? Apart from the bug you manifest, which should not occur, I'd note that back-perl does not support slaptools, and thus no slaptool'ing should occur when using it. I can't debug this right now because I don't routinely build with back-perl. My guess is that the bug should appear with any other glued backend that does not support tools (but I couldn't reproduce it using back-ldap, for example). A (possible) workaround is to use slapcat -a '(!(entryDN:dnSubtreeMatch:=ou=perl,dc=my-domain,dc=com))' in order to exclude the subtree handled by back-perl. p. > > (gdb) bt full > #0 0x00007f18761dded5 in raise () from /lib/libc.so.6 > No symbol table info available. > #1 0x00007f18761df3f3 in abort () from /lib/libc.so.6 > No symbol table info available. > #2 0x00007f187621a3a8 in ?? () from /lib/libc.so.6 > No symbol table info available. > #3 0x00007f187621f948 in ?? () from /lib/libc.so.6 > No symbol table info available. > #4 0x00007f1876221a56 in free () from /lib/libc.so.6 > No symbol table info available. > #5 0x00007f1877296c52 in ber_memfree_x (p=0xa207b3, ctx=0x0) at > memory.c:152 > __PRETTY_FUNCTION__ = "ber_memfree_x" > #6 0x000000000044f785 in ch_free (ptr=0xa207b3) at ch_malloc.c:139 > ctx = (void *) 0x0 > #7 0x00000000004395e6 in entry_clean (e=0xa0bff8) at entry.c:489 > __PRETTY_FUNCTION__ = "entry_clean" > #8 0x00000000004396ab in entry_free (e=0xa0bff8) at entry.c:514 > No locals. > #9 0x00000000004ae4e4 in glue_entry_release_rw (op=0x7fffe262a540, > e=0xa0bff8, rw=0) at backglue.c:731 > b0 = (BackendDB *) 0x7fffe262a2d0 > rc = -1 > #10 0x00000000004b0952 in overlay_entry_release_ov (op=0x7fffe262a540, > e=0xa0bff8, rw=0, on=0x8997d0) at backover.c:421 > oi = (slap_overinfo *) 0x8995f0 > be = (BackendDB *) 0x89a510 > db = {bd_info = 0x8997d0, bd_self = 0x89a510, be_ctrls = > "\000\001\001\001\000\001\000\000\001\000\000\001\001\000\001", '\0' > <repeats 17 times>, "\001", > be_flags = 2328, 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 = 0x899270, be_nsuffix = 0x8992a0, > be_schemadn = {bv_len = 0, > bv_val = 0x0}, be_schemandn = {bv_len = 0, bv_val = 0x0}, be_rootdn > = {bv_len = 30, bv_val = 0x899570 "cn=Manager,dc=my-domain,dc=com"}, > be_rootndn = {bv_len = 30, > bv_val = 0x8995c0 "cn=manager,dc=my-domain,dc=com"}, be_rootpw = > {bv_len = 6, bv_val = 0x8993b0 "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 = 0x0, be_dfltaccess = ACL_READ, be_update_ndn = {bv_len = 0, > bv_val = 0x0}, be_update_refs = 0x0, be_pending_csn_list = 0x8978c0, > be_pcl_mutex = {__data = { > __lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, > __spins = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\0' > <repeats 39 times>, > __align = 0}, be_syncinfo = 0x0, be_pb = 0x0, be_cf_ocs = 0x7b8c00, > be_private = 0x898a30, be_next = {stqe_next = 0x0}} > bi = (BackendInfo *) 0x8995f0 > rc = 32768 > #11 0x00000000004b0ab2 in over_entry_release_rw (op=0x7fffe262a540, > e=0xa0bff8, rw=0) at backover.c:463 > oi = (slap_overinfo *) 0x8995f0 > on = (slap_overinst *) 0x8997d0 > __PRETTY_FUNCTION__ = "over_entry_release_rw" > #12 0x000000000043d3cf in be_entry_release_rw (op=0x7fffe262a540, > e=0xa0bff8, rw=0) at backend.c:880 > No locals. > #13 0x00000000004b5c5b in slapcat (argc=1, argv=0x7fffe262a8e8) at > slapcat.c:117 > data = 0xa20c50 "dn: ou=perl,dc=my-domain,dc=com\nobjectClass: > organizationalUnit\nobjectClass: top\nou: perl\nstructuralObjectClass: > organizationalUnit\nentryUUID: > 6438973e-d5c0-102e-9c05-81e0ba1bb1f2\ncreatorsName: cn=Man"... > len = 388 > e = (Entry *) 0xa0bff8 > id = 3 > rc = 0 > op = {o_hdr = 0x0, o_tag = 0, o_time = 0, o_tincr = 0, o_bd = > 0x898500, o_req_dn = {bv_len = 0, bv_val = 0x0}, o_req_ndn = {bv_len = > 0, bv_val = 0x0}, > o_request = {oq_add = {rs_modlist = 0x0, rs_e = 0x0}, oq_bind = > {rb_method = 0, rb_cred = {bv_len = 0, bv_val = 0x0}, rb_edn = {bv_len = > 0, bv_val = 0x0}, rb_ssf = 0, > rb_mech = {bv_len = 0, bv_val = 0x0}}, oq_compare = {rs_ava = > 0x0}, oq_modify = {rs_mods = {rs_modlist = 0x0, rs_no_opattrs = 0 '\0'}, > rs_increment = 0}, > oq_modrdn = {rs_mods = {rs_modlist = 0x0, rs_no_opattrs = 0 '\0'}, > rs_deleteoldrdn = 0, rs_newrdn = {bv_len = 0, bv_val = 0x0}, rs_nnewrdn > = {bv_len = 0, > bv_val = 0x0}, rs_newSup = 0x0, rs_nnewSup = 0x0}, oq_search = > {rs_scope = 0, rs_deref = 0, rs_slimit = 0, rs_tlimit = 0, rs_limit = > 0x0, rs_attrsonly = 0, > rs_attrs = 0x0, rs_filter = 0x0, rs_filterstr = {bv_len = 0, > bv_val = 0x0}}, oq_abandon = {rs_msgid = 0}, oq_cancel = {rs_msgid = 0}, > oq_extended = {rs_reqoid = { > bv_len = 0, bv_val = 0x0}, rs_flags = 0, rs_reqdata = 0x0}, > oq_pwdexop = {rs_extended = {rs_reqoid = {bv_len = 0, bv_val = 0x0}, > rs_flags = 0, > rs_reqdata = 0x0}, rs_old = {bv_len = 0, bv_val = 0x0}, rs_new > = {bv_len = 0, bv_val = 0x0}, rs_mods = 0x0, rs_modtail = 0x0}}, > o_abandon = 0, o_cancel = 0, > o_groups = 0x0, o_do_not_cache = 0 '\0', o_is_auth_check = 0 '\0', > o_dont_replicate = 0 '\0', o_acl_priv = ACL_NONE, o_nocaching = 0 '\0', > o_delete_glue_parent = 0 '\0', o_no_schema_check = 0 '\0', > o_no_subordinate_glue = 0 '\0', o_ctrlflag = '\0' <repeats 31 times>, > o_controls = 0x0, o_authz = { > sai_method = 0, sai_mech = {bv_len = 0, bv_val = 0x0}, sai_dn = > {bv_len = 0, bv_val = 0x0}, sai_ndn = {bv_len = 0, bv_val = 0x0}, > sai_ssf = 0, > sai_transport_ssf = 0, sai_tls_ssf = 0, sai_sasl_ssf = 0}, o_ber = > 0x0, o_res_ber = 0x0, o_callback = 0x0, o_ctrls = 0x0, o_csn = {bv_len = > 0, bv_val = 0x0}, > o_private = 0x0, o_extra = {slh_first = 0x0}, o_next = {stqe_next = > 0x0}} > progname = 0x55fc68 "slapcat" > #14 0x00000000004090d3 in main (argc=1, argv=0x7fffe262a8e8) at main.c:403 > i = 1 > no_detach = 0 > rc = 1 > urls = 0x0 > username = 0x0 > groupname = 0x0 > sandbox = 0x0 > syslogUser = 160 > g_argc = 1 > g_argv = (char **) 0x7fffe262a8e8 > configfile = 0x0 > configdir = 0x0 > serverName = 0x7fffe262c75e "slapcat" > serverMode = 1 > scp = (struct sync_cookie *) 0x0 > scp_entry = (struct sync_cookie *) 0x0 > debug_unknowns = (char **) 0x0 > syslog_unknowns = (char **) 0x0 > serverNamePrefix = 0x54076b "" > l = 4223483 > slapd_pid_file_unlink = 0 > slapd_args_file_unlink = 0 > firstopt = 1 > __PRETTY_FUNCTION__ = "main" > (gdb) > > > HTH, > > Mark. > > -- > Mark Cave-Ayland - Senior Technical Architect > PostgreSQL - PostGIS > Sirius Corporation plc - control through freedom > http://www.siriusit.co.uk > t: +44 870 608 0063 > > Sirius Labs: http://www.siriusit.co.uk/labs >

1 0

Re: (ITS#6506) Use of back-perl in slapd.conf in subordinate database causes slapcat to segfault
by mark.cave-ayland＠siriusit.co.uk 06 Apr '10

06 Apr '10

masarati(a)aero.polimi.it wrote: >> *** glibc detected *** ./sbin/slapcat: free(): invalid pointer: > > ^^^ this message is not quite informative, nor is what follows below. > Please read <http://www.openldap.org/faq/data/cache/56.html> carefully, > and provide the information required. > > p. Okay. I figured it was easy enough to recreate that I wouldn't need to build a full debug build myself, but looks like I need to do that anyway. Also, what is the best way to not get "strip" to be automatically invoked during "make install"? I ended up temporarily removing the binary just to get unstripped versions. (gdb) bt full #0 0x00007f18761dded5 in raise () from /lib/libc.so.6 No symbol table info available. #1 0x00007f18761df3f3 in abort () from /lib/libc.so.6 No symbol table info available. #2 0x00007f187621a3a8 in ?? () from /lib/libc.so.6 No symbol table info available. #3 0x00007f187621f948 in ?? () from /lib/libc.so.6 No symbol table info available. #4 0x00007f1876221a56 in free () from /lib/libc.so.6 No symbol table info available. #5 0x00007f1877296c52 in ber_memfree_x (p=0xa207b3, ctx=0x0) at memory.c:152 __PRETTY_FUNCTION__ = "ber_memfree_x" #6 0x000000000044f785 in ch_free (ptr=0xa207b3) at ch_malloc.c:139 ctx = (void *) 0x0 #7 0x00000000004395e6 in entry_clean (e=0xa0bff8) at entry.c:489 __PRETTY_FUNCTION__ = "entry_clean" #8 0x00000000004396ab in entry_free (e=0xa0bff8) at entry.c:514 No locals. #9 0x00000000004ae4e4 in glue_entry_release_rw (op=0x7fffe262a540, e=0xa0bff8, rw=0) at backglue.c:731 b0 = (BackendDB *) 0x7fffe262a2d0 rc = -1 #10 0x00000000004b0952 in overlay_entry_release_ov (op=0x7fffe262a540, e=0xa0bff8, rw=0, on=0x8997d0) at backover.c:421 oi = (slap_overinfo *) 0x8995f0 be = (BackendDB *) 0x89a510 db = {bd_info = 0x8997d0, bd_self = 0x89a510, be_ctrls = "\000\001\001\001\000\001\000\000\001\000\000\001\001\000\001", '\0' <repeats 17 times>, "\001", be_flags = 2328, 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 = 0x899270, be_nsuffix = 0x8992a0, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_schemandn = {bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 30, bv_val = 0x899570 "cn=Manager,dc=my-domain,dc=com"}, be_rootndn = {bv_len = 30, bv_val = 0x8995c0 "cn=manager,dc=my-domain,dc=com"}, be_rootpw = {bv_len = 6, bv_val = 0x8993b0 "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 = 0x0, be_dfltaccess = ACL_READ, be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x0, be_pending_csn_list = 0x8978c0, be_pcl_mutex = {__data = { __lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\0' <repeats 39 times>, __align = 0}, be_syncinfo = 0x0, be_pb = 0x0, be_cf_ocs = 0x7b8c00, be_private = 0x898a30, be_next = {stqe_next = 0x0}} bi = (BackendInfo *) 0x8995f0 rc = 32768 #11 0x00000000004b0ab2 in over_entry_release_rw (op=0x7fffe262a540, e=0xa0bff8, rw=0) at backover.c:463 oi = (slap_overinfo *) 0x8995f0 on = (slap_overinst *) 0x8997d0 __PRETTY_FUNCTION__ = "over_entry_release_rw" #12 0x000000000043d3cf in be_entry_release_rw (op=0x7fffe262a540, e=0xa0bff8, rw=0) at backend.c:880 No locals. #13 0x00000000004b5c5b in slapcat (argc=1, argv=0x7fffe262a8e8) at slapcat.c:117 data = 0xa20c50 "dn: ou=perl,dc=my-domain,dc=com\nobjectClass: organizationalUnit\nobjectClass: top\nou: perl\nstructuralObjectClass: organizationalUnit\nentryUUID: 6438973e-d5c0-102e-9c05-81e0ba1bb1f2\ncreatorsName: cn=Man"... len = 388 e = (Entry *) 0xa0bff8 id = 3 rc = 0 op = {o_hdr = 0x0, o_tag = 0, o_time = 0, o_tincr = 0, o_bd = 0x898500, o_req_dn = {bv_len = 0, bv_val = 0x0}, o_req_ndn = {bv_len = 0, bv_val = 0x0}, o_request = {oq_add = {rs_modlist = 0x0, rs_e = 0x0}, oq_bind = {rb_method = 0, rb_cred = {bv_len = 0, bv_val = 0x0}, rb_edn = {bv_len = 0, bv_val = 0x0}, rb_ssf = 0, rb_mech = {bv_len = 0, bv_val = 0x0}}, oq_compare = {rs_ava = 0x0}, oq_modify = {rs_mods = {rs_modlist = 0x0, rs_no_opattrs = 0 '\0'}, rs_increment = 0}, oq_modrdn = {rs_mods = {rs_modlist = 0x0, rs_no_opattrs = 0 '\0'}, rs_deleteoldrdn = 0, rs_newrdn = {bv_len = 0, bv_val = 0x0}, rs_nnewrdn = {bv_len = 0, bv_val = 0x0}, rs_newSup = 0x0, rs_nnewSup = 0x0}, oq_search = {rs_scope = 0, rs_deref = 0, rs_slimit = 0, rs_tlimit = 0, rs_limit = 0x0, rs_attrsonly = 0, rs_attrs = 0x0, rs_filter = 0x0, rs_filterstr = {bv_len = 0, bv_val = 0x0}}, oq_abandon = {rs_msgid = 0}, oq_cancel = {rs_msgid = 0}, oq_extended = {rs_reqoid = { bv_len = 0, bv_val = 0x0}, rs_flags = 0, rs_reqdata = 0x0}, oq_pwdexop = {rs_extended = {rs_reqoid = {bv_len = 0, bv_val = 0x0}, rs_flags = 0, rs_reqdata = 0x0}, rs_old = {bv_len = 0, bv_val = 0x0}, rs_new = {bv_len = 0, bv_val = 0x0}, rs_mods = 0x0, rs_modtail = 0x0}}, o_abandon = 0, o_cancel = 0, o_groups = 0x0, o_do_not_cache = 0 '\0', o_is_auth_check = 0 '\0', o_dont_replicate = 0 '\0', o_acl_priv = ACL_NONE, o_nocaching = 0 '\0', o_delete_glue_parent = 0 '\0', o_no_schema_check = 0 '\0', o_no_subordinate_glue = 0 '\0', o_ctrlflag = '\0' <repeats 31 times>, o_controls = 0x0, o_authz = { sai_method = 0, sai_mech = {bv_len = 0, bv_val = 0x0}, sai_dn = {bv_len = 0, bv_val = 0x0}, sai_ndn = {bv_len = 0, bv_val = 0x0}, sai_ssf = 0, sai_transport_ssf = 0, sai_tls_ssf = 0, sai_sasl_ssf = 0}, o_ber = 0x0, o_res_ber = 0x0, o_callback = 0x0, o_ctrls = 0x0, o_csn = {bv_len = 0, bv_val = 0x0}, o_private = 0x0, o_extra = {slh_first = 0x0}, o_next = {stqe_next = 0x0}} progname = 0x55fc68 "slapcat" #14 0x00000000004090d3 in main (argc=1, argv=0x7fffe262a8e8) at main.c:403 i = 1 no_detach = 0 rc = 1 urls = 0x0 username = 0x0 groupname = 0x0 sandbox = 0x0 syslogUser = 160 g_argc = 1 g_argv = (char **) 0x7fffe262a8e8 configfile = 0x0 configdir = 0x0 serverName = 0x7fffe262c75e "slapcat" serverMode = 1 scp = (struct sync_cookie *) 0x0 scp_entry = (struct sync_cookie *) 0x0 debug_unknowns = (char **) 0x0 syslog_unknowns = (char **) 0x0 serverNamePrefix = 0x54076b "" l = 4223483 slapd_pid_file_unlink = 0 slapd_args_file_unlink = 0 firstopt = 1 __PRETTY_FUNCTION__ = "main" (gdb) HTH, Mark. -- Mark Cave-Ayland - Senior Technical Architect PostgreSQL - PostGIS Sirius Corporation plc - control through freedom http://www.siriusit.co.uk t: +44 870 608 0063 Sirius Labs: http://www.siriusit.co.uk/labs

1 0

Re: (ITS#6506) Use of back-perl in slapd.conf in subordinate database causes slapcat to segfault
by masarati＠aero.polimi.it 06 Apr '10

06 Apr '10

> masarati(a)aero.polimi.it wrote: > >> ^^^ I think the culprit is here. No point in tracking down further this >> issue unless you re-link as recommended by this message. >> >> p. > > Sorry - I experienced the error on a production box running Debian > packages, and re-built from source on my local machine just to confirm > the bug still exists. However, my local machine already has other LDAP > libraries installed which seems to have resulted in some of the wrong > libraries being picked up at compile time. > > I've now removed all pre-built openldap packages, re-built again from > source and can confirm that the bug still stands since the > "ldap_int_global_options" warning has now disappeared: > > > zeno:/home/build/rel-openldap# ./sbin/slapcat > Here in new > Posix Var 8192 and 4096 > bdb_db_open: database "dc=my-domain,dc=com": unclean shutdown detected; > attempting recovery. > bdb_db_open: warning - no DB_CONFIG file found in directory > /home/build/rel-openldap/var/openldap-data: (2). > Expect poor performance for suffix "dc=my-domain,dc=com". > bdb_db_open: database "dc=my-domain,dc=com": recovery skipped in > read-only mode. Run manual recovery if errors are encountered. > bdb_monitor_db_open: monitoring disabled; configure monitor database to > enable > dn: dc=my-domain,dc=com > objectClass: top > objectClass: dcObject > objectClass: organization > o:: bXlkb21haW4uY29tIA== > dc: my-domain > structuralObjectClass: organization > entryUUID: 0bdc2650-d5c0-102e-9fe7-3350c645132d > creatorsName: cn=Manager,dc=my-domain,dc=com > createTimestamp: 20100406120241Z > entryCSN: 20100406120241.310422Z#000000#000#000000 > modifiersName: cn=Manager,dc=my-domain,dc=com > modifyTimestamp: 20100406120241Z > > dn: ou=real,dc=my-domain,dc=com > objectClass: organizationalUnit > objectClass: top > structuralObjectClass: organizationalUnit > entryUUID: 5644fb04-d5c0-102e-9c04-81e0ba1bb1f2 > creatorsName: cn=Manager,dc=my-domain,dc=com > createTimestamp: 20100406120446Z > ou: real > entryCSN: 20100406120458.545769Z#000000#000#000000 > modifiersName: cn=Manager,dc=my-domain,dc=com > modifyTimestamp: 20100406120458Z > > *** glibc detected *** ./sbin/slapcat: free(): invalid pointer: ^^^ this message is not quite informative, nor is what follows below. Please read <http://www.openldap.org/faq/data/cache/56.html> carefully, and provide the information required. p. > 0x00000000009c4fd3 *** > ======= Backtrace: ========= > /lib/libc.so.6[0x7f4ea6fd0948] > /lib/libc.so.6(cfree+0x76)[0x7f4ea6fd2a56] > ./sbin/slapcat[0x42c11d] > ./sbin/slapcat[0x42c1c9] > ./sbin/slapcat[0x481448] > ./sbin/slapcat[0x484c93] > ./sbin/slapcat[0x4874b9] > ./sbin/slapcat[0x408d40] > /lib/libc.so.6(__libc_start_main+0xe6)[0x7f4ea6f7b1a6] > ./sbin/slapcat[0x4087d9] > > > Many thanks, > > Mark. > > -- > Mark Cave-Ayland - Senior Technical Architect > PostgreSQL - PostGIS > Sirius Corporation plc - control through freedom > http://www.siriusit.co.uk > t: +44 870 608 0063 > > Sirius Labs: http://www.siriusit.co.uk/labs >

1 0

Re: (ITS#6506) Use of back-perl in slapd.conf in subordinate database causes slapcat to segfault
by mark.cave-ayland＠siriusit.co.uk 06 Apr '10

06 Apr '10

masarati(a)aero.polimi.it wrote: > ^^^ I think the culprit is here. No point in tracking down further this > issue unless you re-link as recommended by this message. > > p. Sorry - I experienced the error on a production box running Debian packages, and re-built from source on my local machine just to confirm the bug still exists. However, my local machine already has other LDAP libraries installed which seems to have resulted in some of the wrong libraries being picked up at compile time. I've now removed all pre-built openldap packages, re-built again from source and can confirm that the bug still stands since the "ldap_int_global_options" warning has now disappeared: zeno:/home/build/rel-openldap# ./sbin/slapcat Here in new Posix Var 8192 and 4096 bdb_db_open: database "dc=my-domain,dc=com": unclean shutdown detected; attempting recovery. bdb_db_open: warning - no DB_CONFIG file found in directory /home/build/rel-openldap/var/openldap-data: (2). Expect poor performance for suffix "dc=my-domain,dc=com". bdb_db_open: database "dc=my-domain,dc=com": recovery skipped in read-only mode. Run manual recovery if errors are encountered. bdb_monitor_db_open: monitoring disabled; configure monitor database to enable dn: dc=my-domain,dc=com objectClass: top objectClass: dcObject objectClass: organization o:: bXlkb21haW4uY29tIA== dc: my-domain structuralObjectClass: organization entryUUID: 0bdc2650-d5c0-102e-9fe7-3350c645132d creatorsName: cn=Manager,dc=my-domain,dc=com createTimestamp: 20100406120241Z entryCSN: 20100406120241.310422Z#000000#000#000000 modifiersName: cn=Manager,dc=my-domain,dc=com modifyTimestamp: 20100406120241Z dn: ou=real,dc=my-domain,dc=com objectClass: organizationalUnit objectClass: top structuralObjectClass: organizationalUnit entryUUID: 5644fb04-d5c0-102e-9c04-81e0ba1bb1f2 creatorsName: cn=Manager,dc=my-domain,dc=com createTimestamp: 20100406120446Z ou: real entryCSN: 20100406120458.545769Z#000000#000#000000 modifiersName: cn=Manager,dc=my-domain,dc=com modifyTimestamp: 20100406120458Z *** glibc detected *** ./sbin/slapcat: free(): invalid pointer: 0x00000000009c4fd3 *** ======= Backtrace: ========= /lib/libc.so.6[0x7f4ea6fd0948] /lib/libc.so.6(cfree+0x76)[0x7f4ea6fd2a56] ./sbin/slapcat[0x42c11d] ./sbin/slapcat[0x42c1c9] ./sbin/slapcat[0x481448] ./sbin/slapcat[0x484c93] ./sbin/slapcat[0x4874b9] ./sbin/slapcat[0x408d40] /lib/libc.so.6(__libc_start_main+0xe6)[0x7f4ea6f7b1a6] ./sbin/slapcat[0x4087d9] Many thanks, Mark. -- Mark Cave-Ayland - Senior Technical Architect PostgreSQL - PostGIS Sirius Corporation plc - control through freedom http://www.siriusit.co.uk t: +44 870 608 0063 Sirius Labs: http://www.siriusit.co.uk/labs

1 0

Re: (ITS#6506) Use of back-perl in slapd.conf in subordinate database causes slapcat to segfault
by masarati＠aero.polimi.it 06 Apr '10

06 Apr '10

> Full_Name: Mark Cave-Ayland > Version: 2.4.21 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (81.187.123.11) > > > Hi there, > > Having implemented a custom perl module as a subordinate with back-perl, > we've > found a segfault when using slapcat to dump the database. The backtrace > looks > like this: > > > zeno:/home/build/rel-openldap# ./sbin/slapcat > ./sbin/slapcat: Symbol `ldap_int_global_options' has different size in > shared > object, consider re-linking ^^^ I think the culprit is here. No point in tracking down further this issue unless you re-link as recommended by this message. p. > Here in new > Posix Var 8192 and 4096 > bdb_db_open: warning - no DB_CONFIG file found in directory > /home/build/rel-openldap/var/openldap-data: (2). > Expect poor performance for suffix "dc=my-domain,dc=com". > bdb_monitor_db_open: monitoring disabled; configure monitor database to > enable > dn: dc=my-domain,dc=com > objectClass: top > objectClass: dcObject > objectClass: organization > o:: bXlkb21haW4uY29tIA== > dc: my-domain > structuralObjectClass: organization > entryUUID: 0bdc2650-d5c0-102e-9fe7-3350c645132d > creatorsName: cn=Manager,dc=my-domain,dc=com > createTimestamp: 20100406120241Z > entryCSN: 20100406120241.310422Z#000000#000#000000 > modifiersName: cn=Manager,dc=my-domain,dc=com > modifyTimestamp: 20100406120241Z > > dn: ou=real,dc=my-domain,dc=com > objectClass: organizationalUnit > objectClass: top > structuralObjectClass: organizationalUnit > entryUUID: 5644fb04-d5c0-102e-9c04-81e0ba1bb1f2 > creatorsName: cn=Manager,dc=my-domain,dc=com > createTimestamp: 20100406120446Z > ou: real > entryCSN: 20100406120458.545769Z#000000#000#000000 > modifiersName: cn=Manager,dc=my-domain,dc=com > modifyTimestamp: 20100406120458Z > > *** glibc detected *** ./sbin/slapcat: free(): invalid pointer: > 0x00000000009c5063 *** > ======= Backtrace: ========= > /lib/libc.so.6[0x7f1adc150948] > /lib/libc.so.6(cfree+0x76)[0x7f1adc152a56] > ./sbin/slapcat[0x42c11d] > ./sbin/slapcat[0x42c1c9] > ./sbin/slapcat[0x481448] > ./sbin/slapcat[0x484c93] > ./sbin/slapcat[0x4874b9] > ./sbin/slapcat[0x408d40] > /lib/libc.so.6(__libc_start_main+0xe6)[0x7f1adc0fb1a6] > ./sbin/slapcat[0x4087d9] > > > Looks like an invalid pointer is being deferenced when running slapcat. > > > ATB, > > Mark. > > >

1 0

Re: (ITS#6506) Use of back-perl in slapd.conf in subordinate database causes slapcat to segfault
by mark.cave-ayland＠siriusit.co.uk 06 Apr '10

06 Apr '10

Here is the slapd.conf used in the test: # # See slapd.conf(5) for details on configuration options. # This file should NOT be world readable. # include /home/build/rel-openldap/etc/openldap/schema/core.schema # Define global ACLs to disable default read access. # Do not enable referrals until AFTER you have a working directory # service AND an understanding of referrals. #referral ldap://root.openldap.org pidfile /home/build/rel-openldap/var/run/slapd.pid argsfile /home/build/rel-openldap/var/run/slapd.args # Load dynamic backend modules: # modulepath /home/build/rel-openldap/libexec/openldap # moduleload back_bdb.la # moduleload back_hdb.la # moduleload back_ldap.la # Sample security restrictions # Require integrity protection (prevent hijacking) # Require 112-bit (3DES or better) encryption for updates # Require 63-bit encryption for simple bind # security ssf=1 update_ssf=112 simple_bind=64 # Sample access control policy: # Root DSE: allow anyone to read it # Subschema (sub)entry DSE: allow anyone to read it # Other DSEs: # Allow self write access # Allow authenticated users read access # Allow anonymous users to authenticate # Directives needed to implement policy: # access to dn.base="" by * read # access to dn.base="cn=Subschema" by * read # access to * # by self write # by users read # by anonymous auth # # if no access controls are present, the default policy # allows anyone and everyone to read anything but restricts # updates to rootdn. (e.g., "access to * by * read") # # rootdn can always read and write EVERYTHING! database perl suffix "ou=perl,dc=my-domain,dc=com" subordinate perlModulePath /home/build/rel-openldap/etc/openldap perlModule SampleLDAP ####################################################################### # BDB database definitions ####################################################################### database bdb suffix "dc=my-domain,dc=com" rootdn "cn=Manager,dc=my-domain,dc=com" # Cleartext passwords, especially for the rootdn, should # be avoid. See slappasswd(8) and slapd.conf(5) for details. # Use of strong authentication encouraged. rootpw secret # The database directory MUST exist prior to running slapd AND # should only be accessible by the slapd and slap tools. # Mode 700 recommended. directory /home/build/rel-openldap/var/openldap-data # Indices to maintain index objectClass eq And here is the slapcat output when the perl database is disabled in slapd.conf to prevent the crash: dn: dc=my-domain,dc=com objectClass: top objectClass: dcObject objectClass: organization o:: bXlkb21haW4uY29tIA== dc: my-domain structuralObjectClass: organization entryUUID: 0bdc2650-d5c0-102e-9fe7-3350c645132d creatorsName: cn=Manager,dc=my-domain,dc=com createTimestamp: 20100406120241Z entryCSN: 20100406120241.310422Z#000000#000#000000 modifiersName: cn=Manager,dc=my-domain,dc=com modifyTimestamp: 20100406120241Z dn: ou=real,dc=my-domain,dc=com objectClass: organizationalUnit objectClass: top structuralObjectClass: organizationalUnit entryUUID: 5644fb04-d5c0-102e-9c04-81e0ba1bb1f2 creatorsName: cn=Manager,dc=my-domain,dc=com createTimestamp: 20100406120446Z ou: real entryCSN: 20100406120458.545769Z#000000#000#000000 modifiersName: cn=Manager,dc=my-domain,dc=com modifyTimestamp: 20100406120458Z dn: ou=perl,dc=my-domain,dc=com objectClass: organizationalUnit objectClass: top ou: perl structuralObjectClass: organizationalUnit entryUUID: 6438973e-d5c0-102e-9c05-81e0ba1bb1f2 creatorsName: cn=Manager,dc=my-domain,dc=com createTimestamp: 20100406120509Z entryCSN: 20100406120509.555750Z#000000#000#000000 modifiersName: cn=Manager,dc=my-domain,dc=com modifyTimestamp: 20100406120509Z ATB, Mark. -- Mark Cave-Ayland - Senior Technical Architect PostgreSQL - PostGIS Sirius Corporation plc - control through freedom http://www.siriusit.co.uk t: +44 870 608 0063 Sirius Labs: http://www.siriusit.co.uk/labs

1 0

(ITS#6506) Use of back-perl in slapd.conf in subordinate database causes slapcat to segfault
by mark.cave-ayland＠siriusit.co.uk 06 Apr '10

06 Apr '10

Full_Name: Mark Cave-Ayland Version: 2.4.21 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.187.123.11) Hi there, Having implemented a custom perl module as a subordinate with back-perl, we've found a segfault when using slapcat to dump the database. The backtrace looks like this: zeno:/home/build/rel-openldap# ./sbin/slapcat ./sbin/slapcat: Symbol `ldap_int_global_options' has different size in shared object, consider re-linking Here in new Posix Var 8192 and 4096 bdb_db_open: warning - no DB_CONFIG file found in directory /home/build/rel-openldap/var/openldap-data: (2). Expect poor performance for suffix "dc=my-domain,dc=com". bdb_monitor_db_open: monitoring disabled; configure monitor database to enable dn: dc=my-domain,dc=com objectClass: top objectClass: dcObject objectClass: organization o:: bXlkb21haW4uY29tIA== dc: my-domain structuralObjectClass: organization entryUUID: 0bdc2650-d5c0-102e-9fe7-3350c645132d creatorsName: cn=Manager,dc=my-domain,dc=com createTimestamp: 20100406120241Z entryCSN: 20100406120241.310422Z#000000#000#000000 modifiersName: cn=Manager,dc=my-domain,dc=com modifyTimestamp: 20100406120241Z dn: ou=real,dc=my-domain,dc=com objectClass: organizationalUnit objectClass: top structuralObjectClass: organizationalUnit entryUUID: 5644fb04-d5c0-102e-9c04-81e0ba1bb1f2 creatorsName: cn=Manager,dc=my-domain,dc=com createTimestamp: 20100406120446Z ou: real entryCSN: 20100406120458.545769Z#000000#000#000000 modifiersName: cn=Manager,dc=my-domain,dc=com modifyTimestamp: 20100406120458Z *** glibc detected *** ./sbin/slapcat: free(): invalid pointer: 0x00000000009c5063 *** ======= Backtrace: ========= /lib/libc.so.6[0x7f1adc150948] /lib/libc.so.6(cfree+0x76)[0x7f1adc152a56] ./sbin/slapcat[0x42c11d] ./sbin/slapcat[0x42c1c9] ./sbin/slapcat[0x481448] ./sbin/slapcat[0x484c93] ./sbin/slapcat[0x4874b9] ./sbin/slapcat[0x408d40] /lib/libc.so.6(__libc_start_main+0xe6)[0x7f1adc0fb1a6] ./sbin/slapcat[0x4087d9] Looks like an invalid pointer is being deferenced when running slapcat. ATB, Mark.

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs