- openldap-bugs - openldap.org

(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

Re: (ITS#6504) Corrupted control value when using pagedresults with subordinate *ldap* database
by masarati＠aero.polimi.it 05 Apr '10

05 Apr '10

>> Well, I've just fixed it. When changing database, I modified the paged >> results control value by setting the page size to pagesize - >> rs->sr_nentries, with an empty cookie. I'll commit tomorrow, as now I >> only have http access. > > Speedy patch - thank you! Just tried it out, and it works great for the > issue I reported. > > Testing further shows a limitation in crossing databases though. A > search that spans over two glued ldap databases, returns n < pagesize > results from the first, and continues over to the second, returning > pagesize-n results from it, making pagesize results all together. So > far, so good. > > However, the subsequent search with the returned pagedresults cookie > just starts a new search over, returning the same set of results. So it > works fine for one page max. > > But it doesn't look simple to solve this issue, unless backglue starts > recording pagedresults cookies, etc... > > Anyway, great improvement on not sending back free'd cookie :-) I see the issue, and it seems to be not related to my patch. Don't know how to fix it (yet). It'll probably need a separate ITS. p.

1 0

Re: (ITS#6504) Corrupted control value when using pagedresults with subordinate *ldap* database
by jonathan＠phillipoux.net 05 Apr '10

05 Apr '10

Le 02/04/2010 06:44, masarati(a)aero.polimi.it a écrit : >> masarati(a)aero.polimi.it wrote: >>>> masarati(a)aero.polimi.it wrote: >>>>>> Also, I note that the glued paged response seems to work incorrectly. >>>>>> I >>>>>> made a simple test system, where the root database contains exactly >>>>>> one >>>>>> entry (the suffix) and a back-ldap is glued on top. If I request >>>>>> entries >>>>>> with a page size of 2, searching the suffix return 3 entries; >>>>>> subsequent >>>>>> searches return 2 entries from the proxy. I haven't figured out yet >>>>>> where >>>>>> the issue is. >>>>> >>>>> I figured out how to fix the issue you reported. It is related to the >>>>> fact that slapd internally assumes that ldctl_oid values are constant >>>>> strings, so it doesn't duplicate nor free them. However, control OIDs >>>>> returned by back-ldap (and friends) have been decoded from the wire by >>>>> the >>>>> client library, so they are actually malloc'ed. That's why backglue >>>>> ends >>>>> up with a dangling pointer. >>>>> >>>>> I'm fixing it by having backglue duplicate (and free) control OIDs >>>>> consistently. Another option would be to replace those values with >>>>> constant strings for known control values. This would prevent gluing >>>>> for >>>>> unknown proxied controls. >>>> >>>> Or just tmpalloc them and don't bother to clean them up. >>> >>> Yes, I've reworked all the temporary controls allocation using tmpalloc. >>> Too bad OIDs are char* and not bervals. >>> >>> With respect to the other issue, to honor the requested pagesize we'd >>> need >>> to intercept pagedresult requests, modify the page size in the request >>> when a page crosses two databases, requesting the original page size >>> minus >>> entries already returned. I wonder whether it's worth the effort, >>> though. >> >> IMO pagedresults should be a (global) overlay, and backends shouldn't do >> anything about it. Note that the sssvlv overlay already intercepts >> pagedresults, it's impossible to handle things correctly otherwise. > > Well, I've just fixed it. When changing database, I modified the paged > results control value by setting the page size to pagesize - > rs->sr_nentries, with an empty cookie. I'll commit tomorrow, as now I > only have http access. Speedy patch - thank you! Just tried it out, and it works great for the issue I reported. Testing further shows a limitation in crossing databases though. A search that spans over two glued ldap databases, returns n < pagesize results from the first, and continues over to the second, returning pagesize-n results from it, making pagesize results all together. So far, so good. However, the subsequent search with the returned pagedresults cookie just starts a new search over, returning the same set of results. So it works fine for one page max. But it doesn't look simple to solve this issue, unless backglue starts recording pagedresults cookies, etc... Anyway, great improvement on not sending back free'd cookie :-) -- -------------------------------------------------------------- Jonathan Clarke - jonathan(a)phillipoux.net -------------------------------------------------------------- Ldap Synchronization Connector (LSC) - http://lsc-project.org --------------------------------------------------------------

1 0

RE: (ITS#6505) ldap_search_* functions missing const qualifiers
by EHASZLA＠transunion.com 05 Apr '10

05 Apr '10

>From: masarati(a)aero.polimi.it [mailto:masarati@aero.polimi.it] > >> hmm... I'm not quite sure how to attach a file to a ticket through the >> web interface, > >In general, upload to ftp.openldap.org according to contribution >instructions, and post a message with the URL; the way you provided it >makes it pretty unusable. Fwiw, I uploaded the two patches as ehaszla-ldap.h-20100405.patch and ehaszla-search.c-20100405.patch eric

1 0

RE: (ITS#6505) ldap_search_* functions missing const qualifiers
by masarati＠aero.polimi.it 05 Apr '10

05 Apr '10

> Anyway, if the change doesn't get accepted it won't be the end of the > world, but obviously I'm hoping you find the above convincing. Just to clarify: if I were to design the API from scratch, I'd CONST those args... so I agree with your suggestion. p.

1 0

RE: (ITS#6505) ldap_search_* functions missing const qualifiers
by EHASZLA＠transunion.com 04 Apr '10

04 Apr '10

This is a multi-part message in MIME format. ------_=_NextPart_001_01CAD483.E1DB174F Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable -----Original Message----- >From: masarati(a)aero.polimi.it [mailto:masarati@aero.polimi.it] >In general, upload to ftp.openldap.org according to contribution >instructions, and post a message with the URL; the way you provided it >makes it pretty unusable. I saw the instructions about using the ftp site some time after I sent = the patches. Sorry. The patch was just the obvious, mechanical change to add const to the attrs parameter in the functions that have it. Maybe a reminder to keep reading the rest of the page in the section on "patches" would be helpful. I got to the part that started talking = about attribution of large changes, and assumed the rest of the page wasn't relevant to what I was trying to do. >However, I think your patch will not be considered, although in = principle >perfectly acceptable, because an API change of this type would probably >break a lot of code out there, without significant advantages. Well, a couple of observations: 1) At least one other ldap implementation already does this. 2) I consider being able to turn on the compiler warnings that tell you = about parameters that might be changed when do don't expect them to be = a significant advantage. For many of the source trees I've worked on, = doing so (and treating warnings as errors, to force them to be fixed)=20 has helped uncover a variety of bugs. 3) If you're not being pedantic about warnings, and causing them to be=20 treated as errors, this API change just results in an extra warning,=20 which wouldn't actually break any code. 4) Adding "const" effectively and simply documents the fact that those=20 parameters aren't going to be changed. If the API doesn't say so, it would be nice if that was at least explicitly mentions in the man = page. At the moment, I had to go read an analyze the ldap code to figure that out. I'd rather spend my time working on my own code instead, = and be able to simply use the great library you guys have created. :) Anyway, if the change doesn't get accepted it won't be the end of the world, but obviously I'm hoping you find the above convincing. eric ------_=_NextPart_001_01CAD483.E1DB174F Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML> <HEAD> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; = charset=3Diso-8859-1"> <META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version = 6.5.7654.12"> <TITLE>RE: (ITS#6505) ldap_search_* functions missing const = qualifiers</TITLE> </HEAD> <BODY>  -----Original Message----- >From: masarati(a)aero.polimi.it [<A = HREF=3D"mailto:masarati@aero.polimi.it">mailto:masarati@aero.polimi.it</A= >] >In general, upload to ftp.openldap.org according to contribution >instructions, and post a message with the URL; the way you provided = it >makes it pretty unusable.   I saw the instructions about using the ftp site some time after I = sent the patches.  Sorry.  The patch was just the obvious, = mechanical change to add const to the attrs parameter in the functions that have it. Maybe a reminder to keep reading the rest of the page in the section = on "patches" would be helpful.  I got to the part that = started talking about attribution of large changes, and assumed the rest of the page = wasn't relevant to what I was trying to do. >However, I think your patch will not be considered, although in = principle >perfectly acceptable, because an API change of this type would = probably >break a lot of code out there, without significant advantages. Well, a couple of observations:  1) At least one other ldap implementation already does this.  2) I consider being able to turn on the compiler warnings that = tell you   about parameters that might be changed when do don't expect them = to be   a significant advantage.  For many of the source trees I've = worked on,   doing so (and treating warnings as errors, to force them to be = fixed)   has helped uncover a variety of bugs.  3) If you're not being pedantic about warnings, and causing them = to be   treated as errors, this API change just results in an extra = warning,   which wouldn't actually break any code.  4) Adding "const" effectively and simply documents the = fact that those   parameters aren't going to be changed.  If the API doesn't = say so, it   would be nice if that was at least explicitly mentions in the man = page.   At the moment, I had to go read an analyze the ldap code to = figure   that out.  I'd rather spend my time working on my own code = instead, and   be able to simply use the great library you guys have created. = :) Anyway, if the change doesn't get accepted it won't be the end of = the  world, but obviously I'm hoping you find the above convincing. eric </BODY> </HTML> ------_=_NextPart_001_01CAD483.E1DB174F--

1 0

Re: (ITS#6505) ldap_search_* functions missing const qualifiers
by masarati＠aero.polimi.it 02 Apr '10

02 Apr '10

> hmm... I'm not quite sure how to attach a file to a ticket through the > web interface, In general, upload to ftp.openldap.org according to contribution instructions, and post a message with the URL; the way you provided it makes it pretty unusable. However, I think your patch will not be considered, although in principle perfectly acceptable, because an API change of this type would probably break a lot of code out there, without significant advantages. p.

1 0

Re: (ITS#6505) ldap_search_* functions missing const qualifiers
by EHASZLA＠transunion.com 02 Apr '10

02 Apr '10

hmm... I'm not quite sure how to attach a file to a ticket through the web interface, so I'm just going to paste the patches in here: --- ldap.h.1.349.orig 2010-04-02 15:32:34.113126200 -0500 +++ ldap.h 2010-04-02 15:33:55.252793400 -0500 @@ -1841,7 +1841,7 @@ LDAP_CONST char *base, int scope, LDAP_CONST char *filter, - char **attrs, + LDAP_CONST char **attrs, int attrsonly, LDAPControl **serverctrls, LDAPControl **clientctrls, @@ -1855,7 +1855,7 @@ LDAP_CONST char *base, int scope, LDAP_CONST char *filter, - char **attrs, + LDAP_CONST char **attrs, int attrsonly, LDAPControl **serverctrls, LDAPControl **clientctrls, @@ -1870,7 +1870,7 @@ LDAP_CONST char *base, int scope, LDAP_CONST char *filter, - char **attrs, + LDAP_CONST char **attrs, int attrsonly )); =20 LDAP_F( int ) @@ -1879,7 +1879,7 @@ LDAP_CONST char *base, int scope, LDAP_CONST char *filter, - char **attrs, + LDAP_CONST char **attrs, int attrsonly, LDAPMessage **res )); =20 @@ -1889,7 +1889,7 @@ LDAP_CONST char *base, int scope, LDAP_CONST char *filter, - char **attrs, + LDAP_CONST char **attrs, int attrsonly, struct timeval *timeout, LDAPMessage **res )); --- search.c.1.88.orig 2010-04-02 15:26:34.268550800 -0500 +++ search.c 2010-04-02 15:32:36.939198200 -0500 @@ -47,7 +47,7 @@ * attrsonly 1 =3D> attributes only 0 =3D> attributes and values * * Example: - * char *attrs[] =3D { "mail", "title", 0 }; + * const char *attrs[] =3D { "mail", "title", 0 }; * ldap_search_ext( ld, "dc=3Dexample,dc=3Dcom", LDAP_SCOPE_SUBTREE, "cn~=3Dbob", * attrs, attrsonly, sctrls, ctrls, timeout, sizelimit, * &msgid ); @@ -58,7 +58,7 @@ LDAP_CONST char *base, int scope, LDAP_CONST char *filter, - char **attrs, + LDAP_CONST char **attrs, int attrsonly, LDAPControl **sctrls, LDAPControl **cctrls, @@ -76,7 +76,7 @@ LDAP_CONST char *base, int scope, LDAP_CONST char *filter, - char **attrs, + LDAP_CONST char **attrs, int attrsonly, LDAPControl **sctrls, LDAPControl **cctrls, @@ -139,7 +139,7 @@ LDAP_CONST char *base, int scope, LDAP_CONST char *filter, - char **attrs, + LDAP_CONST char **attrs, int attrsonly, LDAPControl **sctrls, LDAPControl **cctrls, @@ -157,7 +157,7 @@ LDAP_CONST char *base, int scope, LDAP_CONST char *filter, - char **attrs, + LDAP_CONST char **attrs, int attrsonly, LDAPControl **sctrls, LDAPControl **cctrls, @@ -210,14 +210,14 @@ * attrsonly 1 =3D> attributes only 0 =3D> attributes and values * * Example: - * char *attrs[] =3D { "mail", "title", 0 }; + * const char *attrs[] =3D { "mail", "title", 0 }; * msgid =3D ldap_search( ld, "dc=3Dexample,dc=3Dcom", LDAP_SCOPE_SUBTREE, "cn~=3Dbob", * attrs, attrsonly ); */ int ldap_search( LDAP *ld, LDAP_CONST char *base, int scope, LDAP_CONST char *filter, - char **attrs, int attrsonly ) + LDAP_CONST char **attrs, int attrsonly ) { BerElement *ber; ber_int_t id; @@ -246,7 +246,7 @@ LDAP_CONST char *base, ber_int_t scope, LDAP_CONST char *filter, - char **attrs, + LDAP_CONST char **attrs, ber_int_t attrsonly, LDAPControl **sctrls, LDAPControl **cctrls, @@ -390,7 +390,7 @@ int ldap_search_st( LDAP *ld, LDAP_CONST char *base, int scope, - LDAP_CONST char *filter, char **attrs, + LDAP_CONST char *filter, LDAP_CONST char **attrs, int attrsonly, struct timeval *timeout, LDAPMessage **res ) { int msgid; @@ -419,7 +419,7 @@ LDAP_CONST char *base, int scope, LDAP_CONST char *filter, - char **attrs, + LDAP_CONST char **attrs, int attrsonly, LDAPMessage **res ) {

1 0

(ITS#6505) ldap_search_* functions missing const qualifiers
by ehaszla＠transunion.com 02 Apr '10

02 Apr '10

Full_Name: Eric Haszlakiewicz Version: cvsweb OS: RHEL5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (12.106.254.66) The ldap_search_ext, ldap_search_ext_s, ldap_search, ldap_search_s and ldap_search_st functions should use const for the attrs parameter. I checked revision 1.88 of libraries/libldap/search.c and it appears that those strings do not get modified so there is no reason that a list of string constants couldn't be passed in. I have a short patch that changes libraries/libldap/search.c and include/ldap.h (rev 1.349) to add the const qualifier.

1 0

Re: (ITS#6504) Corrupted control value when using pagedresults with subordinate *ldap* database
by masarati＠aero.polimi.it 01 Apr '10

01 Apr '10

> masarati(a)aero.polimi.it wrote: >>> masarati(a)aero.polimi.it wrote: >>>>> Also, I note that the glued paged response seems to work incorrectly. >>>>> I >>>>> made a simple test system, where the root database contains exactly >>>>> one >>>>> entry (the suffix) and a back-ldap is glued on top. If I request >>>>> entries >>>>> with a page size of 2, searching the suffix return 3 entries; >>>>> subsequent >>>>> searches return 2 entries from the proxy. I haven't figured out yet >>>>> where >>>>> the issue is. >>>> >>>> I figured out how to fix the issue you reported. It is related to the >>>> fact that slapd internally assumes that ldctl_oid values are constant >>>> strings, so it doesn't duplicate nor free them. However, control OIDs >>>> returned by back-ldap (and friends) have been decoded from the wire by >>>> the >>>> client library, so they are actually malloc'ed. That's why backglue >>>> ends >>>> up with a dangling pointer. >>>> >>>> I'm fixing it by having backglue duplicate (and free) control OIDs >>>> consistently. Another option would be to replace those values with >>>> constant strings for known control values. This would prevent gluing >>>> for >>>> unknown proxied controls. >>> >>> Or just tmpalloc them and don't bother to clean them up. >> >> Yes, I've reworked all the temporary controls allocation using tmpalloc. >> Too bad OIDs are char* and not bervals. >> >> With respect to the other issue, to honor the requested pagesize we'd >> need >> to intercept pagedresult requests, modify the page size in the request >> when a page crosses two databases, requesting the original page size >> minus >> entries already returned. I wonder whether it's worth the effort, >> though. > > IMO pagedresults should be a (global) overlay, and backends shouldn't do > anything about it. Note that the sssvlv overlay already intercepts > pagedresults, it's impossible to handle things correctly otherwise. Well, I've just fixed it. When changing database, I modified the paged results control value by setting the page size to pagesize - rs->sr_nentries, with an empty cookie. I'll commit tomorrow, as now I only have http access. p.

1 0

Re: (ITS#6504) Corrupted control value when using pagedresults with subordinate *ldap* database
by hyc＠symas.com 01 Apr '10

01 Apr '10

masarati(a)aero.polimi.it wrote: >> masarati(a)aero.polimi.it wrote: >>>> Also, I note that the glued paged response seems to work incorrectly. >>>> I >>>> made a simple test system, where the root database contains exactly one >>>> entry (the suffix) and a back-ldap is glued on top. If I request >>>> entries >>>> with a page size of 2, searching the suffix return 3 entries; >>>> subsequent >>>> searches return 2 entries from the proxy. I haven't figured out yet >>>> where >>>> the issue is. >>> >>> I figured out how to fix the issue you reported. It is related to the >>> fact that slapd internally assumes that ldctl_oid values are constant >>> strings, so it doesn't duplicate nor free them. However, control OIDs >>> returned by back-ldap (and friends) have been decoded from the wire by >>> the >>> client library, so they are actually malloc'ed. That's why backglue >>> ends >>> up with a dangling pointer. >>> >>> I'm fixing it by having backglue duplicate (and free) control OIDs >>> consistently. Another option would be to replace those values with >>> constant strings for known control values. This would prevent gluing >>> for >>> unknown proxied controls. >> >> Or just tmpalloc them and don't bother to clean them up. > > Yes, I've reworked all the temporary controls allocation using tmpalloc. > Too bad OIDs are char* and not bervals. > > With respect to the other issue, to honor the requested pagesize we'd need > to intercept pagedresult requests, modify the page size in the request > when a page crosses two databases, requesting the original page size minus > entries already returned. I wonder whether it's worth the effort, though. IMO pagedresults should be a (global) overlay, and backends shouldn't do anything about it. Note that the sssvlv overlay already intercepts pagedresults, it's impossible to handle things correctly otherwise. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6504) Corrupted control value when using pagedresults with subordinate *ldap* database
by masarati＠aero.polimi.it 01 Apr '10

01 Apr '10

> masarati(a)aero.polimi.it wrote: >>> Also, I note that the glued paged response seems to work incorrectly. >>> I >>> made a simple test system, where the root database contains exactly one >>> entry (the suffix) and a back-ldap is glued on top. If I request >>> entries >>> with a page size of 2, searching the suffix return 3 entries; >>> subsequent >>> searches return 2 entries from the proxy. I haven't figured out yet >>> where >>> the issue is. >> >> I figured out how to fix the issue you reported. It is related to the >> fact that slapd internally assumes that ldctl_oid values are constant >> strings, so it doesn't duplicate nor free them. However, control OIDs >> returned by back-ldap (and friends) have been decoded from the wire by >> the >> client library, so they are actually malloc'ed. That's why backglue >> ends >> up with a dangling pointer. >> >> I'm fixing it by having backglue duplicate (and free) control OIDs >> consistently. Another option would be to replace those values with >> constant strings for known control values. This would prevent gluing >> for >> unknown proxied controls. > > Or just tmpalloc them and don't bother to clean them up. Yes, I've reworked all the temporary controls allocation using tmpalloc. Too bad OIDs are char* and not bervals. With respect to the other issue, to honor the requested pagesize we'd need to intercept pagedresult requests, modify the page size in the request when a page crosses two databases, requesting the original page size minus entries already returned. I wonder whether it's worth the effort, though. p.

1 0

Re: (ITS#6504) Corrupted control value when using pagedresults with subordinate *ldap* database
by hyc＠symas.com 01 Apr '10

01 Apr '10

masarati(a)aero.polimi.it wrote: >> Also, I note that the glued paged response seems to work incorrectly. I >> made a simple test system, where the root database contains exactly one >> entry (the suffix) and a back-ldap is glued on top. If I request entries >> with a page size of 2, searching the suffix return 3 entries; subsequent >> searches return 2 entries from the proxy. I haven't figured out yet where >> the issue is. > > I figured out how to fix the issue you reported. It is related to the > fact that slapd internally assumes that ldctl_oid values are constant > strings, so it doesn't duplicate nor free them. However, control OIDs > returned by back-ldap (and friends) have been decoded from the wire by the > client library, so they are actually malloc'ed. That's why backglue ends > up with a dangling pointer. > > I'm fixing it by having backglue duplicate (and free) control OIDs > consistently. Another option would be to replace those values with > constant strings for known control values. This would prevent gluing for > unknown proxied controls. Or just tmpalloc them and don't bother to clean them up. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6504) Corrupted control value when using pagedresults with subordinate *ldap* database
by masarati＠aero.polimi.it 01 Apr '10

01 Apr '10

> Also, I note that the glued paged response seems to work incorrectly. I > made a simple test system, where the root database contains exactly one > entry (the suffix) and a back-ldap is glued on top. If I request entries > with a page size of 2, searching the suffix return 3 entries; subsequent > searches return 2 entries from the proxy. I haven't figured out yet where > the issue is. I figured out how to fix the issue you reported. It is related to the fact that slapd internally assumes that ldctl_oid values are constant strings, so it doesn't duplicate nor free them. However, control OIDs returned by back-ldap (and friends) have been decoded from the wire by the client library, so they are actually malloc'ed. That's why backglue ends up with a dangling pointer. I'm fixing it by having backglue duplicate (and free) control OIDs consistently. Another option would be to replace those values with constant strings for known control values. This would prevent gluing for unknown proxied controls. p.

1 0

Re: (ITS#6504) Corrupted control value when using pagedresults with subordinate *ldap* database
by masarati＠aero.polimi.it 01 Apr '10

01 Apr '10

>> Full_Name: Jonathan Clarke >> Version: RE24 >> OS: >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (193.57.67.241) >> >> >> This is similar to ITS #5191 (http://www.openldap.org/its/?findid=5191), >> except >> it happens with a subordinate LDAP database. >> >> Consider this configuration : >> 8<--------------------------------------- >> database ldap >> suffix "o=test,o=sub" >> uri "ldap://localhost:1234" >> subordinate >> idassert-bind mode=none bindmethod=simple flags=prescriptive timeout=0 >> network-timeout=0 binddn="cn=svc,o=test" credentials="verysecret" >> idassert-authzFrom dn.regex:.* >> single-conn yes >> >> overlay rwm >> rwm-suffixmassage "o=test,o=sub" "o=test" >> >> database null >> suffix "o=sub" >> rootdn "cn=Manager,o=sub" >> rootpw secret >> overlay glue >> 8<--------------------------------------- >> >> A search with pagedResults control returns results as expected, but with >> a >> response control containing some garbage: >> >> result: 0 Success >> control:: >> qOEpCDg0MC4xMTM1NTYuMS40LjMxOSBmYWxzZSBNSVFBQUFBSkFnRUFCQVFFQUFBQQ== >> >> Some gdb'ing shows that backglue copies over the pointers to >> rs->sr_ctrls >> into >> glue_state->ctrls. But then, back-ldap's ldap_back_search does a >> ldap_controls_free() on rs->sr_ctrls. And so, the returned control >> contains >> garbage (mostly). >> >> I haven't been able to come up with a patch yet, just commenting line >> 454 >> of >> back-ldap/search.c works. Running out of time for now... >> >> > > Probably, backglue should rather ldap_controls_dup() them. However, in > this case we need to make sure that the glued databases delete their own > copy. Also, I note that the glued paged response seems to work incorrectly. I made a simple test system, where the root database contains exactly one entry (the suffix) and a back-ldap is glued on top. If I request entries with a page size of 2, searching the suffix return 3 entries; subsequent searches return 2 entries from the proxy. I haven't figured out yet where the issue is. p.

1 0

Re: (ITS#6504) Corrupted control value when using pagedresults with subordinate *ldap* database
by masarati＠aero.polimi.it 01 Apr '10

01 Apr '10

> Full_Name: Jonathan Clarke > Version: RE24 > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (193.57.67.241) > > > This is similar to ITS #5191 (http://www.openldap.org/its/?findid=5191), > except > it happens with a subordinate LDAP database. > > Consider this configuration : > 8<--------------------------------------- > database ldap > suffix "o=test,o=sub" > uri "ldap://localhost:1234" > subordinate > idassert-bind mode=none bindmethod=simple flags=prescriptive timeout=0 > network-timeout=0 binddn="cn=svc,o=test" credentials="verysecret" > idassert-authzFrom dn.regex:.* > single-conn yes > > overlay rwm > rwm-suffixmassage "o=test,o=sub" "o=test" > > database null > suffix "o=sub" > rootdn "cn=Manager,o=sub" > rootpw secret > overlay glue > 8<--------------------------------------- > > A search with pagedResults control returns results as expected, but with a > response control containing some garbage: > > result: 0 Success > control:: > qOEpCDg0MC4xMTM1NTYuMS40LjMxOSBmYWxzZSBNSVFBQUFBSkFnRUFCQVFFQUFBQQ== > > Some gdb'ing shows that backglue copies over the pointers to rs->sr_ctrls > into > glue_state->ctrls. But then, back-ldap's ldap_back_search does a > ldap_controls_free() on rs->sr_ctrls. And so, the returned control > contains > garbage (mostly). > > I haven't been able to come up with a patch yet, just commenting line 454 > of > back-ldap/search.c works. Running out of time for now... > > Probably, backglue should rather ldap_controls_dup() them. However, in this case we need to make sure that the glued databases delete their own copy. p.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs