openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

(ITS#6800) back-meta: pseudorootdn & pseudorootpw deprecated
by masarati＠aero.polimi.it 19 Jan '11

19 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 back-meta's man page lists pseudoroot{dn,pw} as deprecated configuration statements; move them to a separate block. p.

1 0

Re: (ITS#6798) Mutex starvation on two-level referral for SASL connection
by masarati＠aero.polimi.it 19 Jan '11

19 Jan '11

> Full_Name: Stephen Gallagher > Version: 2.4.21-0ubuntu5.2 I think this issue report is obsoleted by ITS#6510 (released with OL 2.4.22), which prevents binds from returning referrals. Please upgrade and re-check. p.

1 0

(ITS#6799) back-meta may erroneously consider as candidates targets outside the scope of a search
by masarati＠aero.polimi.it 19 Jan '11

19 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 meta_back_is_candidate() marks as candidate any target whose suffix is subordinate to the search request when the request has "subtree" scope. This in principle can give false positives and could also give false negatives. However, that piece of code is always exploited with a "subtree" scope, regardless of the actual scope of the search. As a consequence, only false positives can occur (which is harmless but may result in unnecessary activity). The function meta_back_is_candidate() has been fixed to correctly manage all conditions; when called during a search request, the actual scope is used, to make sure only actual candidates are considered by search operations. p.

1 0

(ITS#6798) Mutex starvation on two-level referral for SASL connection
by sgallagh＠redhat.com 19 Jan '11

19 Jan '11

Full_Name: Stephen Gallagher Version: 2.4.21-0ubuntu5.2 OS: Ubuntu 10.04 URL: Submission from: (NULL) (98.110.239.235) This was discovered by a user of SSSD. When referrals are enabled with LDAP_OPT_REFERRALS on, SSSD has a rebind procedure set up to handle authenticating to the new server. This seems to work fine when we're dealing with a simple bind, but when we attempt to use SASL bind (for Kerberos-based GSSAPI authentication), we discovered a problem. Our rebind procedure calls ldap_sasl_interactive_bind_s() with LDAP_SASL_QUIET. This arrangement works fine for a single referral, however if the server has nested referrals (say, entry1 refers to entry2 which refers to entry3 on another server) then we hit a deadlock condition. Attaching gdb, we see the backtrace included at the bottom of this message. What appears to be happening is that for the first ldap_sasl_interactive_bind_s(), openldap is locking a mutex, and when it is called a second time it's attempting to lock that same mutex that has not yet been released. Backtrace: #0 __lll_lock_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:136 No locals. #1 0x00007f48285975d9 in _L_lock_953 () from /lib/libpthread.so.0 No symbol table info available. #2 0x00007f48285973fb in __pthread_mutex_lock (mutex=0x7f4829c05980) at pthread_mutex_lock.c:61 ignore1 = <value optimized out> ignore2 = 700471680 ignore3 = -512 __PRETTY_FUNCTION__ = "__pthread_mutex_lock" type = <value optimized out> #3 0x00007f48299d3e4e in ldap_sasl_interactive_bind_s () from /usr/lib/libldap_r-2.4.so.2 No symbol table info available. #4 0x00007f4825ae00fd in sdap_rebind_proc (ldap=0x2241b80, url=0x2250220 "ldap://DomainDnsZones.org.example.com/DC=DomainDnsZones,DC=org,DC=example,D…", request=<value optimized out>, msgid=<value optimized out>, params=<value optimized out>) at src/providers/ldap/sdap_async_connection.c:1624 p = <value optimized out> sasl_mech = <value optimized out> user_dn = <value optimized out> password = {bv_len = 0, bv_val = 0x0} ctrls = {0x0, 0x0} tmp_ctx = <value optimized out> ret = <value optimized out> __FUNCTION__ = "sdap_rebind_proc" #5 0x00007f48299df6d1 in ldap_new_connection () from /usr/lib/libldap_r-2.4.so.2 No symbol table info available. #6 0x00007f48299e0523 in ldap_send_server_request () from /usr/lib/libldap_r-2.4.so.2 No symbol table info available. #7 0x00007f48299e11cd in ldap_chase_v3referrals () from /usr/lib/libldap_r-2.4.so.2 No symbol table info available. #8 0x00007f48299cbf95 in ?? () from /usr/lib/libldap_r-2.4.so.2 No symbol table info available. #9 0x00007f48299ccc2d in ldap_result () from /usr/lib/libldap_r-2.4.so.2 No symbol table info available. #10 0x00007f48299d4788 in ldap_sasl_bind_s () from /usr/lib/libldap_r-2.4.so.2 No symbol table info available. #11 0x00007f48299d1751 in ldap_int_sasl_bind () from /usr/lib/libldap_r-2.4.so.2 No symbol table info available. #12 0x00007f48299d3ea8 in ldap_sasl_interactive_bind_s () from /usr/lib/libldap_r-2.4.so.2 No symbol table info available. #13 0x00007f4825ae00fd in sdap_rebind_proc (ldap=0x2241b80, url=0x225bc20 "ldap://ForestDnsZones.org.example.com/DC=ForestDnsZones,DC=org,DC=example,D…", request=<value optimized out>, msgid=<value optimized out>, params=<value optimized out>) at src/providers/ldap/sdap_async_connection.c:1624 p = <value optimized out> sasl_mech = <value optimized out> user_dn = <value optimized out> password = {bv_len = 0, bv_val = 0x0} ctrls = {0x0, 0x0} tmp_ctx = <value optimized out> ret = <value optimized out> __FUNCTION__ = "sdap_rebind_proc" #14 0x00007f48299df6d1 in ldap_new_connection () from /usr/lib/libldap_r-2.4.so.2 No symbol table info available. #15 0x00007f48299e0523 in ldap_send_server_request () from /usr/lib/libldap_r-2.4.so.2 No symbol table info available. #16 0x00007f48299e11cd in ldap_chase_v3referrals () from /usr/lib/libldap_r-2.4.so.2 No symbol table info available. #17 0x00007f48299cbf95 in ?? () from /usr/lib/libldap_r-2.4.so.2 No symbol table info available. #18 0x00007f48299ccc2d in ldap_result () from /usr/lib/libldap_r-2.4.so.2 No symbol table info available. #19 0x00007f4825acfcb4 in sdap_process_result (ev=0x221b1f0, pvt=<value optimized out>) at src/providers/ldap/sdap_async.c:178 sh = 0x2241650 no_timeout = {tv_sec = 0, tv_usec = 0} te = <value optimized out> msg = <value optimized out> ret = <value optimized out> __FUNCTION__ = "sdap_process_result" #20 0x00007f482b4f1825 in ?? () from /usr/lib/libtevent.so.0 No symbol table info available. #21 0x00007f482b4f363b in ?? () from /usr/lib/libtevent.so.0 No symbol table info available. #22 0x00007f482b4f09f0 in _tevent_loop_once () from /usr/lib/libtevent.so.0 No symbol table info available. #23 0x00007f482b4f0a5b in ?? () from /usr/lib/libtevent.so.0 No symbol table info available. #24 0x0000000000431e51 in server_loop (main_ctx=0x221c360) at src/util/server.c:526 No locals. #25 0x000000000040f8bb in main (argc=5, argv=<value optimized out>) at src/providers/data_provider_be.c:1333 opt = <value optimized out> pc = <value optimized out> be_domain = 0x2212490 "AALTO" srv_name = <value optimized out> conf_entry = <value optimized out> main_ctx = 0x221c360 ret = 0 long_options = {{longName = 0x0, shortName = 0 '\000', argInfo = 4, arg = 0x644d00, val = 0, descrip = 0x436e64 "Help options:", argDescrip = 0x0}, { longName = 0x436e72 "debug-level", shortName = 100 'd', argInfo = 2, arg = 0x644de0, val = 0, descrip = 0x436e43 "Debug level", argDescrip = 0x0}, { longName = 0x436e7e "debug-to-files", shortName = 102 'f', argInfo = 0, arg = 0x644de4, val = 0, descrip = 0x437ad8 "Send the debug output to files instead of stderr", argDescrip = 0x0}, {longName = 0x436e8d "debug-timestamps", shortName = 0 '\000', argInfo = 2, arg = 0x644cc0, val = 0, descrip = 0x436e4f "Add debug timestamps", argDescrip = 0x0}, {longName = 0x438458 "domain", shortName = 0 '\000', argInfo = 1, arg = 0x7fffe703f208, val = 0, descrip = 0x437b10 "Domain of the information provider (mandatory)", argDescrip = 0x0}, {longName = 0x0, shortName = 0 '\000', argInfo = 0, arg = 0x0, val = 0, descrip = 0x0, argDescrip = 0x0}} __FUNCTION__ = "main"

1 0

Re: (ITS#6796) overlay proxycache
by masarati＠aero.polimi.it 19 Jan '11

19 Jan '11

Apparently it works. p. ÷ÁÒÎÁËÏ× ëÉÒÉÌÌ wrote: > It works!!! > > 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. >

1 0

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

19 Jan '11

It works!!! 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. -- Best regards

1 0

Re: (ITS#6785) slapo-chain mishandles sr_text/sr_matched
by h.b.furuseth＠usit.uio.no 19 Jan '11

19 Jan '11

masarati(a)aero.polimi.it writes: > What do you suggest? To use a local SlapReply instead of hijacking the > one passed as argument? Not my call, I haven't looked enough at the code to know what it's doing. -- Hallvard

1 0

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

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