openldap-bugs

openldap-bugs@openldap.org

1 participants
21000 discussions

Re: (ITS#6796) overlay proxycache
by varnakov-k＠ya.ru 19 Jan '11

19 Jan '11

Thank you for fix, soon i test it. 18.01.2011, 22:47, masarati(a)aero.polimi.it: >> Full_Name: Varnakov Kiril >> Version: openldap-sasl-server-2.4.23 >> OS: FreeBSD 8.0-RELEASE-p3 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (89.235.170.154) >> >> Hi. When i configure ldap server with overlay proxycache and set >> pcachePersist=TRUE, only positive answer stay in cache after restart proxy >> ldap. >> If not restart proxy ldap, all good, negative answer in cache stay. Why? >> >> proxyTemplate (target=) 0 18400 18400 > > Good catch; a fix is in HEAD. Please test it (pcache.c 1.218 -> 1.219) > and report. Please also note that while tracking this issue I also > spotted a couple of bugs which have been fixed as ITS#6797 (pcache.c 1.217 > -> 1.218). > > p. -- C Õ×ÁÖÅÎÉÅÍ, ÷ÁÒÎÁËÏ× ëÉÒÉÌÌ. ôÅÌÅÆÏÎ: +79153349954 ICQ: 3442880

1 0

Re: (ITS#6788) Only one reference when ldap_open_internal_connection
by hyc＠symas.com 18 Jan '11

18 Jan '11

masarati(a)aero.polimi.it wrote: >> Full_Name: Jiri Giesl >> Version: 2.3.43 >> OS: Linux >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (212.111.5.220) >> >> >> We tried to estalish connection to LDAP server by our own (because of >> proxy >> usage) and then use "ldap_open_internal_connection" function to initialize >> internal structures of openldap. After successful SASL binding we realized >> that >> the connection to LDAP server has been closed. We found out that there is >> checking for reference count in "wait4msg" function (result.c file) this >> way: >> >> if ( lc->lconn_refcnt<= 1 ) >> >> During classic initialization and SASL binding we get 2 references, >> however when >> using "ldap_open_internal_connection" and SASL binding we get only 1 >> reference. >> >> We realized that in "ldap_open_defconn" (function which is called for >> establishing of a new connection) there is reference counter which is >> increased >> this way: >> >> ++ld->ld_defconn->lconn_refcnt; /* so it never gets closed/freed */ >> >> When we added this incrementation also into >> "ldap_open_internal_connection" >> (open.c file), everything goes well (it is obvious). >> >> Are we wrong or this is really minor bug (missing incrementation of >> reference >> counter in "ldap_open_internal_connection")? > > Your comment sounds fine; however, it's hard to judge: that code is > essentially untouched since 2000 (Mark Adamson) and it is not (or no > longer) used elsewhere in OpenLDAP code. I'd vote for adding a > > ++ld->ld_defconn->lconn_refcnt; > > here as well, unless someone else has valid objections. I'd say they should rewrite their code to use ldap_init_fd() instead; since open_internal_connection does not provide a URL some SASL mechanisms would fail because they don't know the remote hostname. But yeah, probably adding the refcnt is OK. -- -- 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#6785) slapo-chain mishandles sr_text/sr_matched
by masarati＠aero.polimi.it 18 Jan '11

18 Jan '11

> Full_Name: Hallvard B Furuseth > Version: HEAD > OS: > URL: > Submission from: (NULL) (193.157.198.89) > Submitted by: hallvard > > > ldap_chain_response() can send sr_text/sr_matched which refers to a > different error than sr_err and rc. > > It saves rs-> sr_err, sr_text, sr_matched to three local variables and > can restore them later, but not maintain the text and matched variables > in parallel with err. Also it does not track/reset/obey > REP_MATCHED_MUSTBEFREED along with sr_matched. > > Fails test032-chain with the asserts below. However there may be > non-success result with the wrong text/matched too, that cannot be > assert()ed. > > Come to think of it, maybe the last issues applies to ITS#6774 too? > REP_MATCHED_MUSTBEFREED, mismatch between failure code and text/matched. > > Index: servers/slapd/back-ldap/chain.c > @@ -1019,4 +1019,14 @@ ldap_chain_response( Operation *op, SlapReply *rs ) > rs->sr_ref = NULL; > > + const char *bad_incoming_matched = NULL, *bad_incoming_text = NULL; > + switch ( sr_err ) { > + case LDAP_SUCCESS: > + case LDAP_COMPARE_TRUE: > + case LDAP_COMPARE_FALSE: > + bad_incoming_matched = matched; > + case LDAP_REFERRAL: > + bad_incoming_text = text; > + } > + > /* we need this to know if back-ldap returned any result */ > lb.lb_lc = lc; > @@ -1169,4 +1179,15 @@ cannot_chain:; > > dont_chain:; > + switch ( sr_err ) { > + case LDAP_SUCCESS: > + case LDAP_COMPARE_TRUE: > + case LDAP_COMPARE_FALSE: > + assert( !matched || bad_incoming_matched ); > + case LDAP_REFERRAL: > + assert( !text || bad_incoming_text ); > + } > + assert( rc != LDAP_SUCCESS || > + (( !text || bad_incoming_text) && > + ( !matched || bad_incoming_matched ))); > rs->sr_err = sr_err; > rs->sr_type = sr_type; What do you suggest? To use a local SlapReply instead of hijacking the one passed as argument? p.

1 0

Re: (ITS#6788) Only one reference when ldap_open_internal_connection
by masarati＠aero.polimi.it 18 Jan '11

18 Jan '11

> Full_Name: Jiri Giesl > Version: 2.3.43 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (212.111.5.220) > > > We tried to estalish connection to LDAP server by our own (because of > proxy > usage) and then use "ldap_open_internal_connection" function to initialize > internal structures of openldap. After successful SASL binding we realized > that > the connection to LDAP server has been closed. We found out that there is > checking for reference count in "wait4msg" function (result.c file) this > way: > > if ( lc->lconn_refcnt <= 1 ) > > During classic initialization and SASL binding we get 2 references, > however when > using "ldap_open_internal_connection" and SASL binding we get only 1 > reference. > > We realized that in "ldap_open_defconn" (function which is called for > establishing of a new connection) there is reference counter which is > increased > this way: > > ++ld->ld_defconn->lconn_refcnt; /* so it never gets closed/freed */ > > When we added this incrementation also into > "ldap_open_internal_connection" > (open.c file), everything goes well (it is obvious). > > Are we wrong or this is really minor bug (missing incrementation of > reference > counter in "ldap_open_internal_connection")? Your comment sounds fine; however, it's hard to judge: that code is essentially untouched since 2000 (Mark Adamson) and it is not (or no longer) used elsewhere in OpenLDAP code. I'd vote for adding a ++ld->ld_defconn->lconn_refcnt; here as well, unless someone else has valid objections. p.

1 0

Re: (ITS#6739) broken do_syncrep2()
by hyc＠symas.com 18 Jan '11

18 Jan '11

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 > > > slapd/syncrepl.c:do_syncrep2() initializes many variables once which > should have been initialized inside the loop. > > I'll add the initializations I can figure out, and move most variables > into the loop for readability. > > TODO: > > Variables 'm' and 'refreshDeletes' may still be wrong. In particular > 'm'. It "feels" like it should be local to the loop, but there's no > logic that I can see to prevent previous value from being used. > Perhaps they depend on the peer not breaking the sync protocol? > I haven't read that myself, I'm just peering at the code. The refreshPresent/refreshDeletes flags handling is pretty bogus, I agree. It's always been like that and I've never felt like taking the time to clean it up. It Would Be Nice if someone went thru and cleaned up the entire consumer. While the provider was completely rewritten for 2.3, the consumer is still just a series of patches on the original 2.2 code, and it was never good code to begin with. > I've added three somewhat arbitrary bits of code for error handling: > - A Debug() statement on line 847 which can likely be improved. > - Set err and rc to LDAP_OTHER on ldap_parse_result/ldap_get_option > failure. The correct fix would be proper error checks (ITS#6738), > but I don't know what to do on error. > Sounds like LDAP_OTHER is fine; ldap_get_option should never fail and if it does, we have no idea what's going on anyway. -- -- 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#6796) overlay proxycache
by masarati＠aero.polimi.it 18 Jan '11

18 Jan '11

> Full_Name: Varnakov Kiril > Version: openldap-sasl-server-2.4.23 > OS: FreeBSD 8.0-RELEASE-p3 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (89.235.170.154) > > > Hi. When i configure ldap server with overlay proxycache and set > pcachePersist=TRUE, only positive answer stay in cache after restart proxy > ldap. > If not restart proxy ldap, all good, negative answer in cache stay. Why? > > proxyTemplate (target=) 0 18400 18400 Good catch; a fix is in HEAD. Please test it (pcache.c 1.218 -> 1.219) and report. Please also note that while tracking this issue I also spotted a couple of bugs which have been fixed as ITS#6797 (pcache.c 1.217 -> 1.218). p.

1 0

(ITS#6797) Misc issues related to "pcachePersist"
by masarati＠aero.polimi.it 18 Jan '11

18 Jan '11

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (188.153.31.111) Submitted by: ando found while tracking ITS#6796, not strictly related. A fix is coming. p.

1 0

Re: (ITS#6789) SDAP_DIAGNOSTIC_MESSAGE returns (null) for ldap_install_tls() failures
by rmeggins＠redhat.com 18 Jan '11

18 Jan '11

The problem is that NSS does not provide an error code to descriptive error string mapping. It needs to be added. Can the Subject of this bug be changed to something like LDAP_OPT_DIAGNOSTIC_MESSAGE should return descriptive message when using MozNSS for TLS

1 0

(ITS#6796) overlay proxycache
by varnakov-k＠ya.ru 18 Jan '11

18 Jan '11

Full_Name: Varnakov Kiril Version: openldap-sasl-server-2.4.23 OS: FreeBSD 8.0-RELEASE-p3 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (89.235.170.154) Hi. When i configure ldap server with overlay proxycache and set pcachePersist=TRUE, only positive answer stay in cache after restart proxy ldap. If not restart proxy ldap, all good, negative answer in cache stay. Why? proxyTemplate (target=) 0 18400 18400

1 0

(ITS#6795) syncprov leaks sr_ctrls
by hyc＠OpenLDAP.org 17 Jan '11

17 Jan '11

Full_Name: Howard Chu Version: HEAD/RE24 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.94.188.8) Submitted by: hyc In syncprov_search_response() the control created by syncprov_state_ctrl() can be leaked because the REP_CTRLS_MUSTBEFREED flag was not set.

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