openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

Re: (ITS#6745) HEAD emfile race condition -> slapd stopping listening?
by hyc＠symas.com 23 Dec '10

23 Dec '10

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: HEAD > OS: > URL: > Submission from: (NULL) (129.240.6.233) > Submitted by: hallvard > > > In HEAD slapd/daemon.c, thanks to HEAD's multiple listener support: > > slap_listener() protects emfile with slap_daemon[0 ].sd_mutex, > but slapd_remove() protects it with slap_daemon[id].sd_mutex. > > Maybe to compensate, slapd_remove() has code which checks if emfile > is too big, but nothing checks if it is too small - which looks like > slapd might never start listening again. > > Simplest fix: add this to slapd_remove(): > > if (id) ldap_pvt_thread_mutex_<lock,unlock>(&slap_daemon[0].sd_mutex ); > > slap_daemon[0].sd_mutex looks quite contended that way, though. > Maybe a separate emfile_mutex is better. Alternatively, just skip the check entirely when id != 0. Which would mean that only closing a session on the first listener would ever trigger the other listeners to be unmuted. Doesn't seem so terrible; if slapd is actually out of descriptors one or two connections either way won't make a huge difference in service. -- -- 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#6449) roadmap update
by hyc＠symas.com 23 Dec '10

23 Dec '10

quanah(a)OpenLDAP.org wrote: > Full_Name: Quanah Gibson-Mount > Version: NA > OS: NA > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.29.239) > > > http://www.openldap.org/software/roadmap.html needs to be updated to note that > OpenLDAP 2.3 is no longer maintained, same as 2.2 and prior. > Fixed in CVS. Kurt, can you refresh the web site? -- -- 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#6453) OpenLDAP memory leak on LDAP_TIMEOUT
by hyc＠symas.com 23 Dec '10

23 Dec '10

alinachegalati(a)yahoo.com wrote: > Full_Name: Alin Vasile > Version: 2.4.19 > OS: Solaris 10 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (194.237.142.7) > A patch for this is now in CVS HEAD. > > Hi, > > We have a memory leak LDAP_TIMEOUT is encountered on > ldap_search_ext_invocation and we are unable to determine if it is related to > OpenLdap or not. The following summarizes our code in case the LDAP_TIMEOUT > response is returned : > > LDAPMessage *res ; > > // acquire connection > > // perform search > > if(rc == LDAP_TIMEOUT) > { > ldap_msgfree(res); > // return connection > } > > Is ldap_msgfree(res) enough in this case ? > > We tested our program by enabling a low timeout and hence all ldap calls > resulting in timeout. The memory leak is about 9 Megs in several minutes, at a > load of 5 req/ sec. > > dmalloc sees the following not allocated pointers > > 6642692 bytes : Line 640 of "io.c" starts at address 0xff2659c4 > <ber_get_next+468> and ends at 0xff2659cc<ber_get_next+476>. > > 2019876 bytes : Line 277 of "memory.c" starts at address 0xff26676c > <ber_memcalloc_x+132> and ends at 0xff266774<ber_memcalloc_x+140>. > > > -- -- 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#6680) slapd why sasl error message?
by Howard Chu 23 Dec '10

23 Dec '10

>From your log info, your client is obviously using SASL DIGEST-MD5. There is nothing relevant to slapd or the OpenLDAP code here, fix your client if you want these errors to stop. Closing this ITS.

1 0

Fwd: (ITS#6750) About 3rd Party Technical Support Services
by kurt＠OpenLDAP.org 23 Dec '10

23 Dec '10

--Apple-Mail-80--876671303 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Begin forwarded message: > From: "harrybetter" <harrybetter(a)qq.com> > Date: December 22, 2010 10:32:22 PM PST > To: "Kurt Zeilenga" <kurt(a)openldap.org> > Subject: Re: (ITS#6750) About 3rd Party Technical Support Services > x-spam-status: No, score=3D-0.5 required=3D5.0 = tests=3DBAYES_00,DKIM_SIGNED, = FILL_THIS_FORM_FRAUD_PHISH,FREEMAIL_FROM,FROM_EXCESS_BASE64,HTML_MESSAGE, = RCVD_IN_DNSWL_NONE,T_DKIM_INVALID,T_FILL_THIS_FORM_SHORT,T_RP_MATCHES_RCVD= autolearn=3Dno version=3D3.3.1 >=20 > =20 > anwser is below. >=20 > Please provide the URL for your website/webpage to which your listing = should be linked to? > answer : www.seojindsa.kr >=20 > Please provide a URL to a webpage at your website which details = technical support services=20 > which are specifically tailored to users of OpenLDAP Software? (may be = same as the above URL) > answer : www.seojindsa.kr >=20 > Please provide a summary of your current participation in the OpenLDAP = community? > anwser : Provides consultancy, development, training and user support = for OpenLDAP Software in korea, china. > we will convert openldap document by korean, chinese. >=20 > Please provide an email address (possibly yours) at a domain = registered to SeojinDSA we can use to confirm your association with = SeojinDSA?=20 > answer : sjsong(a)seojindsa.kr=20 >=20 > =20 > =20 > ------------------ Original ------------------ > From: "Kurt Zeilenga"<kurt(a)OpenLDAP.org>; > Date: Thu, Dec 16, 2010 11:36 AM > To: "harrybetter"<harrybetter(a)qq.com>; > Cc: "openldap-its"<openldap-its(a)openldap.org>; > Subject: Re: (ITS#6750) About 3rd Party Technical Support Services > =20 >=20 > On Dec 15, 2010, at 5:27 PM, harrybetter(a)qq.com wrote: >=20 > > Full_Name: Jerry Liu > > Version: openldap-2.4.23 > > OS: RedHatLinux EL5 > > URL: ftp://ftp.openldap.org/incoming/ > > Submission from: (NULL) (221.0.151.187) > >=20 > >=20 > > We are SeojinDSA CO,LTD. We sincerely hope to show our company = name and link > > on list of "Technical Support" page. But we do not know how to = apply, I hope > > this reply. >=20 > By filing an ITS with your request, you have applied. >=20 > > SeojinDSA is an emerging leader in the Korean field of = next-generation > > Directory Service(LDAP) and Identity Managerment(IAM:Identity Access > > Management????The company's headquarter is in Seoul.Our Company is = made up of > > experts and thought leaders who are recognized for building = world-class > > Directory Service. >=20 > A couple of questions. >=20 > Please provide the URL for your website/webpage to which your listing = should be linked to? > Please provide a URL to a webpage at your website which details = technical support services which are specifically tailored to users of = OpenLDAP Software? (may be same as the above URL) > Please provide a summary of your current participation in the OpenLDAP = community? > Please provide an email address (possibly yours) at a domain = registered to SeojinDSA we can use to confirm your association with = SeojinDSA? If you do not wish this email to be made public (all = openldap-its(a)openldap.org is public), you may send this email address = directly to me at <kurt(a)openldap.org>. >=20 > (It's okay for the above requested URLs to refer to non-English web = pages.) >=20 > Regards, Kurt --Apple-Mail-80--876671303 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii <html><head></head><body style=3D"word-wrap: break-word; = -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; = "><br><div><br><div>Begin forwarded message:</div><br = class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><div = style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; = margin-left: 0px;"><span style=3D"font-family:'Helvetica'; = font-size:medium; color:rgba(0, 0, 0, 1);"><b>From: </b></span><span = style=3D"font-family:'Helvetica'; font-size:medium;">"harrybetter" = <<a = href=3D"mailto:harrybetter@qq.com">harrybetter(a)qq.com</a>><br></span></= div><div style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: = 0px; margin-left: 0px;"><span style=3D"font-family:'Helvetica'; = font-size:medium; color:rgba(0, 0, 0, 1);"><b>Date: </b></span><span = style=3D"font-family:'Helvetica'; font-size:medium;">December 22, 2010 = 10:32:22 PM PST<br></span></div><div style=3D"margin-top: 0px; = margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span = style=3D"font-family:'Helvetica'; font-size:medium; color:rgba(0, 0, 0, = 1);"><b>To: </b></span><span style=3D"font-family:'Helvetica'; = font-size:medium;">"Kurt Zeilenga" <<a = href=3D"mailto:kurt@openldap.org">kurt(a)openldap.org</a>><br></span></di= v><div style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; = margin-left: 0px;"><span style=3D"font-family:'Helvetica'; = font-size:medium; color:rgba(0, 0, 0, 1);"><b>Subject: </b></span><span = style=3D"font-family:'Helvetica'; font-size:medium;"><b>Re: (ITS#6750) = About 3rd Party Technical Support Services</b><br></span></div><div = style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; = margin-left: 0px;"><span style=3D"font-family:'Helvetica'; = font-size:medium; color:rgba(0, 0, 0, 1);"><b>x-spam-status: = </b></span><span style=3D"font-family:'Helvetica'; = font-size:medium;">No, score=3D-0.5 required=3D5.0 = tests=3DBAYES_00,DKIM_SIGNED, = FILL_THIS_FORM_FRAUD_PHISH,FREEMAIL_FROM,FROM_EXCESS_BASE64,HTML_MESSAGE, = RCVD_IN_DNSWL_NONE,T_DKIM_INVALID,T_FILL_THIS_FORM_SHORT,T_RP_MATCHES_RCVD= autolearn=3Dno = version=3D3.3.1<br></span></div><br><div><includetail> </includetail>= </div> <div> <div style=3D"COLOR: #000"> <div><p style=3D"MARGIN-TOP: 5px" class=3D"fcknormal">anwser is = below.</p><p style=3D"MARGIN-TOP: 5px" class=3D"fcknormal">Please = provide the URL for your website/webpage to which your listing should be = linked to?<br>answer : <a href=3D"http://www.seojindsa.kr/" = target=3D"_blank"><font = color=3D"#1e5494">www.seojindsa.kr</font></a></p><p style=3D"MARGIN-TOP: = 5px" class=3D"fcknormal">Please provide a URL to a webpage at your = website which details technical support services <br>which are = specifically tailored to users of OpenLDAP Software? (may be same as the = above URL)<br>answer : <a href=3D"http://www.seojindsa.kr/" = target=3D"_blank"><font = color=3D"#1e5494">www.seojindsa.kr</font></a></p><p style=3D"MARGIN-TOP: = 5px" class=3D"fcknormal">Please provide a summary of your current = participation in the OpenLDAP community?<br>anwser : Provides = consultancy, development, training and user support for OpenLDAP = Software in korea, china.<br>         = we will convert openldap document by korean, chinese.</p><p = style=3D"MARGIN-TOP: 5px" class=3D"fcknormal">Please provide an email = address (possibly yours) at a domain registered to SeojinDSA we can use = to confirm your association with SeojinDSA? <br>answer : <a = href=3D"mailto:sjsong@seojindsa.kr" target=3D"_blank"><font = color=3D"#1e5494">sjsong(a)seojindsa.kr</font></a> </p></div> <div> <div> </div> <div> </div> <div style=3D"COLOR: #000"> <div style=3D"PADDING-BOTTOM: 2px; PADDING-LEFT: 0px; PADDING-RIGHT: = 0px; FONT-FAMILY: Arial Narrow; FONT-SIZE: 12px; PADDING-TOP: = 2px">------------------ Original ------------------</div> <div style=3D"PADDING-BOTTOM: 8px; PADDING-LEFT: 8px; PADDING-RIGHT: = 8px; BACKGROUND: #efefef; FONT-SIZE: 12px; PADDING-TOP: 8px"> <div id=3D"menu_sender"><b>From: </b> "Kurt Zeilenga"<<a = href=3D"mailto:kurt@OpenLDAP.org">kurt(a)OpenLDAP.org</a>>;</div> <div><b>Date: </b> Thu, Dec 16, 2010 11:36 AM</div> <div><b>To: </b> "harrybetter"<<a = href=3D"mailto:harrybetter@qq.com">harrybetter(a)qq.com</a>>; = <wbr></div> <div><b>Cc: </b> "openldap-its"<<a = href=3D"mailto:openldap-its@openldap.org">openldap-its(a)openldap.org</a>&gt= ;; <wbr></div> <div><b>Subject: </b> Re: (ITS#6750) About 3rd Party Technical = Support Services</div></div> <div> </div><br>On Dec 15, 2010, at 5:27 PM, <a = href=3D"mailto:harrybetter@qq.com">harrybetter(a)qq.com</a> = wrote:<br><br>> Full_Name: Jerry Liu<br>> Version: = openldap-2.4.23<br>> OS: RedHatLinux EL5<br>> URL: <a = href=3D"ftp://ftp.openldap.org/incoming/">ftp://ftp.openldap.org/incoming/= </a><br>> Submission from: (NULL) (221.0.151.187)<br>> <br>> = <br>>    We are SeojinDSA CO,LTD. We sincerely hope to show = our company name and link<br>> on list of "Technical Support" page. = But we do not know how to apply, I hope<br>> this reply.<br><br>By = filing an ITS with your request, you have applied.<br><br>>  =   SeojinDSA is an emerging leader in the Korean field of = next-generation<br>> Directory Service(LDAP) and Identity = Managerment(IAM:Identity Access<br>> Management????The company's = headquarter is in Seoul.Our Company is made up of<br>> experts and = thought leaders who are recognized for building world-class<br>> = Directory Service.<br><br>A couple of questions.<br><br>Please provide = the URL for your website/webpage to which your listing should be linked = to?<br>Please provide a URL to a webpage at your website which details = technical support services which are specifically tailored to users of = OpenLDAP Software? (may be same as the above URL)<br>Please provide a = summary of your current participation in the OpenLDAP = community?<br>Please provide an email address (possibly yours) at a = domain registered to SeojinDSA we can use to confirm your association = with SeojinDSA?  If you do not wish this email to be made public = (all <a = href=3D"mailto:openldap-its@openldap.org">openldap-its(a)openldap.org</a> = is public), you may send this email address directly to me at <<a = href=3D"mailto:kurt@openldap.org">kurt(a)openldap.org</a>>.<br><br>(It's = okay for the above requested URLs to refer to non-English web = pages.)<br><br>Regards, = Kurt</div></div></div></div></blockquote></div><br></body></html>= --Apple-Mail-80--876671303--

1 0

Re: (ITS#6478) slapd crashes with segfault
by hyc＠symas.com 20 Dec '10

20 Dec '10

wolfgang.hummel(a)hp.com wrote: > We had some of this crashes on LDAP slaves in the past: This appears to be due to your custom template overlay. You probably need to check its correctness using a tool like valgrind or Purify. > In /var/log/messages > 2010-12-05T11:22:57.643777+01:00 ts2mstsv001 kernel: 6>slapd[18900000000000= > 0025 rip 0000003be707p 000000 > > Stack trace when crash occurred (search for entry 0xe932208 in back db (BD= > B) response is contained a corrupted address) > #0 0x0000003be7075b50 in strcpy () from /lib64/libc.so.6 > #1 0x00002b5ffe3debeb in template_response (op=3D0xfa01aa0, rs=3D0x4813bc6= > 0) at /usr/include/bits/string3.h:118 > #2 0x00000000004a34eb in over_back_response (op=3D0xfa01aa0, rs=3D0x4813bc= > 60) at ../servers/slapd/backover.c:237 > #3 0x0000000000449865 in slap_response_play (op=3D0xfa01aa0, rs=3D0x4813bc= > 60) at ../servers/slapd/result.c:402 > #4 0x000000000044bfcc in slap_send_search_entry (op=3D0xfa01aa0, rs=3D0x48= > 13bc60) at ../servers/slapd/result.c:887 > #5 0x00000000004b695f in bdb_search (op=3D0xfa01aa0, rs=3D0x4813bc60) at s= > ervers/slapd/back-bdb/search.c:961 > #6 0x00000000004a37c2 in overlay_op_walk (op=3D0xfa01aa0, rs=3D0x4813bc60,= > which=3Dop_search, oi=3D0xe5df160, on=3D0x0) at ../servers/slapd/backover.= > c:669 > #7 0x00000000004a3d58 in over_op_func (op=3D0xfa01aa0, rs=3D0x4813bc60, wh= > ich=3Dop_search) at ../servers/slapd/backover.c:721 > #8 0x000000000043c4e6 in fe_op_search (op=3D0xfa01aa0, rs=3D0x4813bc60) at= > ../servers/slapd/search.c:376 > #9 0x00000000004a37c2 in overlay_op_walk (op=3D0xfa01aa0, rs=3D0x4813bc60,= > which=3Dop_search, oi=3D0xe577ec0, on=3D0x0) at ../servers/slapd/backover.= > c:669 > #10 0x00000000004a3d58 in over_op_func (op=3D0xfa01aa0, rs=3D0x4813bc60, wh= > ich=3Dop_search) at ../servers/slapd/backover.c:721 > #11 0x000000000043cc95 in do_search (op=3D0xfa01aa0, rs=3D0x4813bc60) at ..= > /servers/slapd/search.c:227 > #12 0x0000000000439ff4 in connection_operation (ctx=3D0x4813bdb0, arg_v=3D<= > value optimized out>) at ../servers/slapd/connection.c:1109 > #13 0x000000000043a651 in connection_read_thread (ctx=3D0x4813bdb0, argv=3D= > <value optimized out>) at ../servers/slapd/connection.c:1245 > #14 0x00000000005330a8 in ldap_int_thread_pool_wrapper (xpool=3D0xe546600) = > at ../libraries/libldap_r/tpool.c:685 > #15 0x0000003be7c062e7 in start_thread () from /lib64/libpthread.so.0 > #16 0x0000003be70ce3bd in clone () from /lib64/libc.so.6 > > (gdb) fr 11 > #11 0x000000000043cc95 in do_search (op=3D0xfa01aa0, rs=3D0x4813bc60) at ..= > /servers/slapd/search.c:227 > 227 ../servers/slapd/search.c: No such file or directory. > in ../servers/slapd/search.c > (gdb) p * op > $55 =3D {o_hdr =3D 0xfa01c10, o_tag =3D 99, o_time =3D 1291544577, o_tincr = > =3D 140, o_bd =3D 0x47fb9ea0, o_req_dn =3D {bv_len =3D 41, bv_val =3D 0x102= > 51e00 "ou=3Dcms,ou=3Dprofiles,ou=3Dmmo,c=3Dde,o=3Dvodafone"}, > o_req_ndn =3D {bv_len =3D 41, bv_val =3D 0x10251ee0 "ou=3Dcms,ou=3Dprofil= > es,ou=3Dmmo,c=3Dde,o=3Dvodafone"}, o_request =3D {oq_add =3D {rs_modlist = > =3D 0x2, rs_e =3D 0x500000064}, oq_bind =3D {rb_method =3D 2, > rb_cred =3D {bv_len =3D 21474836580, bv_val =3D 0x0}, rb_edn =3D {bv_= > len =3D 0, bv_val =3D 0x10251fc0 "\020"}, rb_ssf =3D 270868336, rb_mech =3D= > {bv_len =3D 18, > bv_val =3D 0x10251f98 "(uid=3D491710471677)"}}, oq_compare =3D {rs_= > ava =3D 0x2}, oq_modify =3D {rs_mods =3D {rs_modlist =3D 0x2, rs_no_opattrs= > =3D 100 'd'}, rs_increment =3D 0}, oq_modrdn =3D { > rs_mods =3D {rs_modlist =3D 0x2, rs_no_opattrs =3D 100 'd'}, rs_delet= > eoldrdn =3D 0, rs_newrdn =3D {bv_len =3D 0, bv_val =3D 0x10251fc0 "\020"}, = > rs_nnewrdn =3D {bv_len =3D 270868336, > bv_val =3D 0x12<Address 0x12 out of bounds>}, rs_newSup =3D 0x1025= > 1f98, rs_nnewSup =3D 0x0}, oq_search =3D {rs_scope =3D 2, rs_deref =3D 0, r= > s_slimit =3D 100, rs_tlimit =3D 5, > rs_limit =3D 0x0, rs_attrsonly =3D 0, rs_attrs =3D 0x10251fc0, rs_fil= > ter =3D 0x10251f70, rs_filterstr =3D {bv_len =3D 18, bv_val =3D 0x10251f98 = > "(uid=3D491710471677)"}}, oq_abandon =3D { > rs_msgid =3D 2}, oq_cancel =3D {rs_msgid =3D 2}, oq_extended =3D {rs_= > reqoid =3D {bv_len =3D 2, bv_val =3D 0x500000064<Address 0x500000064 out o= > f bounds>}, rs_flags =3D 0, rs_reqdata =3D 0x0}, > oq_pwdexop =3D {rs_extended =3D {rs_reqoid =3D {bv_len =3D 2, bv_val = > =3D 0x500000064<Address 0x500000064 out of bounds>}, rs_flags =3D 0, rs_re= > qdata =3D 0x0}, rs_old =3D {bv_len =3D 270868416, > bv_val =3D 0x10251f70 "=A3"}, rs_new =3D {bv_len =3D 18, bv_val =3D= > 0x10251f98 "(uid=3D491710471677)"}, rs_mods =3D 0x0, rs_modtail =3D 0x0}},= > o_abandon =3D 0, o_cancel =3D 0, o_groups =3D 0x0, > o_do_not_cache =3D 0 '\0', o_is_auth_check =3D 0 '\0', o_dont_replicate = > =3D 0 '\0', o_acl_priv =3D ACL_NONE, o_nocaching =3D 0 '\0', o_delete_glue_= > parent =3D 0 '\0', o_no_schema_check =3D 0 '\0', > o_no_subordinate_glue =3D 0 '\0', o_ctrlflag =3D '\0'<repeats 31 times>,= > o_controls =3D 0xfa01d58, o_authz =3D {sai_method =3D 128, sai_mech =3D {b= > v_len =3D 0, bv_val =3D 0x0}, sai_dn =3D { > bv_len =3D 51, bv_val =3D 0x2aaab89f0a50 "uid=3Dadmin,ou=3Dcms,ou=3Dp= > rofiles,ou=3Dmmo,c=3Dde,o=3Dvodafone"}, sai_ndn =3D {bv_len =3D 51, > bv_val =3D 0x2aaab8a04e20 "uid=3Dadmin,ou=3Dcms,ou=3Dprofiles,ou=3Dmm= > o,c=3Dde,o=3Dvodafone"}, sai_ssf =3D 0, sai_transport_ssf =3D 0, sai_tls_ss= > f =3D 0, sai_sasl_ssf =3D 0}, o_ber =3D 0x2aaac8098630, > o_res_ber =3D 0x0, o_callback =3D 0x4813a740, o_ctrls =3D 0x0, o_csn =3D = > {bv_len =3D 0, bv_val =3D 0x0}, o_private =3D 0x0, o_extra =3D {slh_first = > =3D 0x4813a480}, o_next =3D {stqe_next =3D 0x0}} > (gdb) p * rs > $56 =3D {sr_type =3D REP_SEARCH, sr_tag =3D 0, sr_msgid =3D 0, sr_err =3D 0= > , sr_matched =3D 0x0, sr_text =3D 0x0, sr_ref =3D 0x0, sr_ctrls =3D 0x0, sr= > _un =3D {sru_search =3D {r_entry =3D 0xe932208, > r_attr_flags =3D 17, r_operational_attrs =3D 0x0, r_attrs =3D 0x10251= > fc0, r_nentries =3D 0, r_v2ref =3D 0x0}, sru_sasl =3D {r_sasldata =3D 0xe93= > 2208}, sru_extended =3D { > r_rspoid =3D 0xe932208 "\2002\a", r_rspdata =3D 0x11}}, sr_flags =3D = > 4} > > Frame analysis (function called) > (gdb) fr 0 > #0 0x0000003be7075b50 in strcpy () from /lib64/libc.so.6 > (gdb) info registers > rax 0x1 1 > rbx 0x1 1 > rcx 0x3 3 > rdx 0x47f37648 1207137864 > rsi 0x25 37 > rdi 0x47f37648 1207137864 > rbp 0x47f265e4 0x47f265e4 > rsp 0x47a25518 0x47a25518 > r8 0xfefefefefefefeff -72340172838076673 > r9 0x4813bdd0 1209253328 > r10 0x2aaab8000020 46912719814688 > r11 0x206 518 > r12 0xe5e2ae0 241052384 > r13 0x0 0 > r14 0xfa01aa0 262150816 > r15 0x6 6 > rip 0x3be7075b50 0x3be7075b50<strcpy+16> > eflags 0x10217 [ CF PF AF IF RF ] > cs 0x33 51 > ss 0x2b 43 > ds 0x0 0 > es 0x0 0 > fs 0x63 99 > gs 0x0 0 > (gdb) disas=20 > Dump of assembler code for function strcpy: > 0x0000003be7075b40<strcpy+0>: mov %rsi,%rcx > 0x0000003be7075b43<strcpy+3>: and $0x7,%ecx > 0x0000003be7075b46<strcpy+6>: mov %rdi,%rdx > 0x0000003be7075b49<strcpy+9>: je 0x3be7075b66<strcpy+38> > 0x0000003be7075b4b<strcpy+11>: neg %ecx > 0x0000003be7075b4d<strcpy+13>: add $0x8,%ecx > 0x0000003be7075b50<strcpy+16>: mov (%rsi),%al > > rsi is a parameter of strcpy.=20 > rsi should be an address but we have 0x25 which is an invalid address. So c= > rash 2010-12-05T11:22:57.643777+01:00 ts2mstsv001 kernel: 6>slapd[189000000= > 000000025 rip 0000003be707p 000000 > rsi is not modified in strcpy, then, check rsi calculation in template_resp= > onse > > (gdb) fr 1 > #1 0x00002b5ffe3debeb in template_response (op=3D0xfa01aa0, rs=3D0x4813bc6= > 0) at /usr/include/bits/string3.h:118 > 118 return __builtin___strcpy_chk (__dest, __src, __bos (__dest)); > (gdb) info registers > rax 0x1 1 > rbx 0x1 1 > rcx 0x3 3 > rdx 0x47f37648 1207137864 > rsi 0x25 37 > rdi 0x47f37648 1207137864 > rbp 0x47f265e4 0x47f265e4 > rsp 0x47a25520 0x47a25520 > r8 0xfefefefefefefeff -72340172838076673 > r9 0x4813bdd0 1209253328 > r10 0x2aaab8000020 46912719814688 > r11 0x206 518 > r12 0xe5e2ae0 241052384 > r13 0x0 0 > r14 0xfa01aa0 262150816 > r15 0x6 6 > rip 0x2b5ffe3debeb 0x2b5ffe3debeb<template_response+3787> > eflags 0x10217 [ CF PF AF IF RF ] > cs 0x33 51 > ss 0x2b 43 > ds 0x0 0 > es 0x0 0 > fs 0x63 99 > gs 0x0 0 > > (gdb) disass 0x00002b5ffe3debeb > Dump of assembler code for function template_response: > ... > 0x00002b5ffe3deb86<template_response+3686>: lea 0x5010c4(%rsp),%rbp > 0x00002b5ffe3deb8e<template_response+3694>: xor %r15d,%r15d > 0x00002b5ffe3deb91<template_response+3697>: xor %r13d,%r13d > 0x00002b5ffe3deb94<template_response+3700>: mov %rdx,0x30(%rsp) > 0x00002b5ffe3deb99<template_response+3705>: mov %rcx,0x28(%rsp) > 0x00002b5ffe3deb9e<template_response+3710>: jmp 0x2b5ffe3dec07<temp= > late_response+3815> > 0x00002b5ffe3deba0<template_response+3712>: mov 0x511900(%rsp),%rax > 0x00002b5ffe3deba8<template_response+3720>: test %rax,%rax > 0x00002b5ffe3debab<template_response+3723>: je 0x2b5ffe3debeb<temp= > late_response+3787> > 0x00002b5ffe3debad<template_response+3725>: mov 0x8(%rax),%rsi > 0x00002b5ffe3debb1<template_response+3729>: test %rsi,%rsi > 0x00002b5ffe3debb4<template_response+3732>: je 0x2b5ffe3debeb<temp= > late_response+3787> > 0x00002b5ffe3debb6<template_response+3734>: cmpq $0x7ff,(%rax) > 0x00002b5ffe3debbd<template_response+3741>: ja 0x2b5ffe3df966<temp= > late_response+7238> > 0x00002b5ffe3debc3<template_response+3747>: movslq 0x512124(%rsp),%rdi > 0x00002b5ffe3debcb<template_response+3755>: mov 0x28(%rsp),%rdx > 0x00002b5ffe3debd0<template_response+3760>: lea 0x1(%rdi),%eax > 0x00002b5ffe3debd3<template_response+3763>: shl $0xb,%rdi > 0x00002b5ffe3debd7<template_response+3767>: lea 0x808(%rdi,%rdx,1),%= > rdi > 0x00002b5ffe3debdf<template_response+3775>: mov %eax,0x512124(%rsp) > 0x00002b5ffe3debe6<template_response+3782>: callq 0x2b5ffe3dc688<strc= > py@plt> > 0x00002b5ffe3debeb<template_response+3787>: lea 0x1(%r13),%eax > (gdb) p *(long **)($rsp+0x511900) > $17 =3D (long *) 0x2aaab4859d00 > (gdb) x/20x 0x2aaab4859d00 > 0x2aaab4859d00: 0x00000000 0x00000000 0x00000025 0x00000000 > > rsi is broken, not a valid address. > > > Wolfgang Hummel > > > -- -- 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#6747) LDAP_CONNECTIONLESS nitpicks
by Kurt＠OpenLDAP.org 20 Dec '10

20 Dec '10

On Dec 20, 2010, at 2:51 AM, Hallvard B Furuseth wrote: > Kurt(a)OpenLDAP.org writes: >> My nitpick regarding this feature is that it still exists. :-) >=20 > Actually there still are complaints that OpenLDAP has lost cldap - = from > people trying to get Windows/Samba to cooperate with OpenLDAP. That's MSCLDAP not CLDAP. Just another nitpick. > Windows > apparently sends a cldap message as an "LDAP ping". > http://ubuntuforums.org/showthread.php?t=3D673292 > http://onemansjourneyintolinux.blogspot.com/2008/06/cldap.html >=20 > Personally I only compiled it since it exists - I randomize my config > options a bit now and then for testing. I suggest that those that care about MSCLDAP or CLDAP, submit patches to = correct any issues they with its implementation. Continuing bitrot, to = me, is an indication that the code should be removed. -- Kurt=

1 0

Re: (ITS#6747) LDAP_CONNECTIONLESS nitpicks
by h.b.furuseth＠usit.uio.no 20 Dec '10

20 Dec '10

Kurt(a)OpenLDAP.org writes: > My nitpick regarding this feature is that it still exists. :-) Actually there still are complaints that OpenLDAP has lost cldap - from people trying to get Windows/Samba to cooperate with OpenLDAP. Windows apparently sends a cldap message as an "LDAP ping". http://ubuntuforums.org/showthread.php?t=673292 http://onemansjourneyintolinux.blogspot.com/2008/06/cldap.html Personally I only compiled it since it exists - I randomize my config options a bit now and then for testing. -- Hallvard

1 0

(ITS#6753) Compare operation broken with attribute inheritance
by h.b.furuseth＠usit.uio.no 20 Dec '10

20 Dec '10

Full_Name: Hallvard B Furuseth Version: HEAD OS: Linux URL: Submission from: (NULL) (193.157.200.213) Submitted by: hallvard back-bdb, back-monitor: If attr A is ACL-protected and inherits from B, one can still check its value with ldapcompare ... 'B:value'. back-config: Compare doesn't seem to support attribute inheritance. root DSE, cn=subschema: Inheritance works correctly. ######## acl.conf include servers/slapd/schema/core.schema rootdse root.ldif access to attrs=st,cn by * none access to * by * read database bdb suffix o=foo directory acl.dir dbconfig set_flags DB_LOG_AUTOREMOVE database monitor database config access to * by * read ######## root.ldif dn: objectClass: extensibleObject st: hidden ######## slapadd: acl.ldif dn: o=foo objectClass: organization st: hidden ######## Results. cn=config should get TRUE, others UNDEFINED. ldapcompare -x cn=config name:config -> UNDEFINED, No such attribute (16) ldapcompare -x cn=config cn:config -> TRUE ldapcompare -x o=foo name:hidden -> TRUE ldapcompare -x o=foo st:hidden -> UNDEFINED, Insufficient access (50) ldapcompare -x cn=monitor name:monitor -> TRUE ldapcompare -x cn=monitor cn:monitor -> UNDEFINED, Insufficient access (50) ldapcompare -x '' name:hidden -> UNDEFINED, Insufficient access (50) ldapcompare -x '' cn:hidden -> UNDEFINED, Insufficient access (50) ldapcompare -x cn=subschema cn:subschema ->UNDEFINED,Insufficient access (50) ldapcompare -x cn=subschema name:subschema ->UNDEFINED,Insufficient access (50)

1 0

(ITS#6752) slapo-dynlist issues
by h.b.furuseth＠usit.uio.no 20 Dec '10

20 Dec '10

Full_Name: Hallvard B Furuseth Version: 2.4.23 OS: URL: Submission from: (NULL) (193.157.200.213) Submitted by: hallvard Dynlist Compare operation: - dynlist_compare() can use an entry after it has been released. It thinks that clearing rs->sr_entry prevents a search from releasing the entry, even after the search completes. Not so. Dynlist mostly worked anyway, I think because dynlist itself follows this expectation for entries without REP_ENTRY_MODIFIABLE which it has duplicated. That includes entries it receives directly from back-bdb. - dynlist_compare() can do needless work: search the same entry several times, fetch an entry to search in a backend which does not support searching, find authz for an entry which will not be searched. - dynlist_sc_save_entry() could read rs->sr_entry when rs->sr_type != REP_SEARCH, which means some other part of the union may be in use. Search operation: - dynlist_sc_update() did not clear REP_ENTRY_MODIFIABLE when freeing. - dynlist_prepare_entry() did not honor REP_ENTRY_MUSTRELEASE. OpenLDAP 2.2/2.3 compatibility code: - Can be dropped, recent dynlist.c does not compile on these versions. Fixing. Simplest Compare fix will ignore errors from o.o_bd->be_search(), just like dynlist_prepare_entry() does.

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