openldap-bugs

openldap-bugs@openldap.org

1 participants
20964 discussions

Re: (ITS#6801) New feature, add subtree-include support in meta backend
by masarati＠aero.polimi.it 20 Jan '11

20 Jan '11

jorge.perez.burgos(a)ericsson.com wrote: > Full_Name: Jorge Perez Burgos > Version: 2.4.21 > OS: linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (195.235.15.243) > > > I'd suggest to introduce a "subtree-include" directive, mutually exclusive with > "subtree-exclude", with different syntaxes, like: > > "[dn[.<style>]:]<pattern>" > > where <style> can be "subtree" or "regex" (other styles like "exact", > "onelevel", "subordinate" could make sense but would be of limited usefulness); > so, for example > > "dn.subtree:<dn>" ("dn.subtree" implicit for backward compatibility) > "dn.regex:<pattern>" > > The "dn.<style>:" prefix is consistent with other features like ACLs, limits and > so. There's ITS#5877 open about making this uniform across slapd for all > features. > > Multiple patterns could be defined; the first that matches would stop execution. > If configured as "subtree-exclude", a match would qualify the target as > "non-candidate" (current behavior for "subtree-exclude"). If configured as > "subtree-include", a match would qualify the target as "candidate". Jorge and I discussed this off-line; suggestions are welcome, otherwise I'd implement it this way right now with ad-hoc code, and eventually turn it into a generally useful feature that could be reused in ACLs, limits, authz, and in other to-be-defined features. p.

1 0

Re: (ITS#6798) Mutex starvation on two-level referral for SASL connection
by h.b.furuseth＠usit.uio.no 20 Jan '11

20 Jan '11

hyc(a)symas.com writes: > Looks like libldap needs to be changed to actually record the tag of the > outgoing requests. (It ought to do so anyway, and probably should return a > ProtocolError result if it receives a response message whose tag doesn't match > its request type.) Yes. OpenLDAP is too trunsting of incoming PDUs to be valid. ...as an option, if this would be noticeable for a lot of users. Users who Just Want Their Programs To Work without OpenLDAP breaking them, and won't be interested in "finger-pointing" against someone else's servers. -- Hallvard

1 0

(ITS#6801) New feature, add subtree-include support in meta backend
by jorge.perez.burgos＠ericsson.com 20 Jan '11

20 Jan '11

Full_Name: Jorge Perez Burgos Version: 2.4.21 OS: linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (195.235.15.243) I'd suggest to introduce a "subtree-include" directive, mutually exclusive with "subtree-exclude", with different syntaxes, like: "[dn[.<style>]:]<pattern>" where <style> can be "subtree" or "regex" (other styles like "exact", "onelevel", "subordinate" could make sense but would be of limited usefulness); so, for example "dn.subtree:<dn>" ("dn.subtree" implicit for backward compatibility) "dn.regex:<pattern>" The "dn.<style>:" prefix is consistent with other features like ACLs, limits and so. There's ITS#5877 open about making this uniform across slapd for all features. Multiple patterns could be defined; the first that matches would stop execution. If configured as "subtree-exclude", a match would qualify the target as "non-candidate" (current behavior for "subtree-exclude"). If configured as "subtree-include", a match would qualify the target as "candidate".

1 0

Re: (ITS#6798) Mutex starvation on two-level referral for SASL connection
by hyc＠symas.com 20 Jan '11

20 Jan '11

sgallagh(a)redhat.com wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 01/19/2011 11:39 AM, masarati(a)aero.polimi.it wrote: >>> 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. > > Upgraded to 2.4.23 and the same behavior occurs. I note in issue 6510 > that it was suggested that nested mutexes could be used to resolve this. > Perhaps we should revisit that. No. Nested mutexes are non-portable, and as already discussed in #6510, it is incorrect to process referrals returned in response to Bind requests. > As you can see from our backtrace, this is actually occurring during the > processing of ldap_result(). We're handling a rebind as ldap_result > travels through a series of referrals. Most likely your server is not using an actual Bind Response tag in its response message. It would be good if you could run this using a debug build (no optimization, full debug symbols present) and examine the tag that was parsed from the referral result. Looks like libldap needs to be changed to actually record the tag of the outgoing requests. (It ought to do so anyway, and probably should return a ProtocolError result if it receives a response message whose tag doesn't match its request type.) -- -- 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#6758) Cleaning up SlapReply usage
by h.b.furuseth＠usit.uio.no 19 Jan '11

19 Jan '11

I wrote: > In addition to the issues listed in my last message, this ITS depends > on these: [ITS#6763,#6776#6760]. Sorry, that was quite wrong. The changes done so far can stand alone, I've tried hard for that. Taking this ITS _further_ depends on those ITSes. But those ITSes are safest to tackle after the changes I've done so far. I've done this ITS backwards after some IRC miscommunication and by sitting too close to the code: First commit a huge patch to clean up SlapReply, then explain why. Sorry about that. I intended to get it done for 2.4.24, but when Howard balked at this approach I expect I instead ended up complicating HEAD->RE24 merges. So to explain better: This is ITS#5340 with a better name. See http://www.openldap.org/its/?findid=5340#followup16 - 18 which actually explains most of the rationale for these changes: "I'm a bit nervous about doing more than minimal fixes to this until we do something major, because it's so broken. (...) [Howard suggested] code which puts something into a SlapReply should ensure it's taken out again. (...) I think that's not the right fix because it's the most fragile solution: Practically every module which depends on it can break if some other module gets it wrong. OTOH, modules can't just reset SlapReply since some of it is input values to op_*() (...)" SlapReply is so broken and confusing that for 3 years I've not dared to do the obvious fixes to ITS#5340. Early on I kept prompting others who understood slapd better than me to take on #5430, but nothing happened. So now I've "done something major": Cleaned up SlapReply enough that it's no longer an act of bravery to take on the original issues. Most of the changes are a preliminary cleanup for going for the original ITS#5340 fixes (obeying the flags). elsewhere: By the original design, it's not a bug for an op_*() function to expect an incoming SlapReply to be clean, nor to output a "dirty" SlapReply, so it' has got to be wrong to reuse a SlapReply without cleaning it up. So I've taken a simpler and more robust approach this time, adding bigger but more trivial changes: In addition to cleaning up some flags, I've killed most cases of SlapReply reuse, which also isolates what damage one module can do to another through SlapReply. Even if they are third-party overlays where the first is broken because it accurately copied what OpenLDAP's overlays were doing:( I've also mostly fixed rs.sr_type. That one was almost as broken, somewhat in the spirit of this awful and confusing idea in result.c: /* FIXME: I think rs->sr_type should be explicitly set to * REP_SEARCH here. That's what it was when we entered this * function. send_ldap_error may have changed it, but we * should set it back so that the cleanup functions know * what they're doing. */ No. If something set rs.sr_type = REP_INTERMEDIATE, result.c should not tell its caller that OID rs.sr_rspoid is an entry, rs.sr_entry. As for user-visible issues the cleanup caught: Half of my December and January ITSes came from this effort. Some minor, some bigger. Generally issues somewhat out of scope of what I was doing in this ITS. Howard asked if all these changes fixed any crashes. Thinking it over, I've had few crashes because of this mess, and I have had a hard time trying to remember which ones. I've had many crashes in the truckload of asserts I added in my private code, which pointed out these ITSes and how to clean up. I could not have found the ITSes before the cleanup, since the asserts then brought down slapd in an instant. Also I've broken slapd a number of times by attempting "obvious" fixes before cleaning up, because slapd is more creative than me about reusing SlapReply strangely. Like pcache.c which reused a Search SlapReply with an entry in it for be_modify() and expected the entry to still be there after the modify:-( Looks like a good candidate for trying to construct a pre-cleanup crash, if I ever find time to try: Find a way to feed that SlapReply to something which reuses it for a Search or an Intermediate Response, thus overwriting the entry sitting in the Modify SlapReply. That kind if thing is why I'm much more eager to get the initial cleanup into RE24 than to get the final entry leak fixes etc into RE24. After the cleanup, there should only be an entry in there if sr_type is REP_SEARCH/REP_SEARCHREF, not also REP_RESULT/REP_GLUE_RESULT as before. ITSes: ITS#6760 slapo-rwm broken entry handling ITS#6752 slapo-dynlist issues [+ related non-SlapReply issues] ITS#6746, #6763 entry/control leaks [+ related non-SlapReply issues] My commits using rs_flush_entry() & co have fixed some other entry leaks or potential leaks. Some modules - in particular BDB - catch potential leaks of their entries. Others do not, giving us memory leaks. ITS#6731, #6748 used scrambled sr_text on an exited function's stack. ITS#6774, ITS#6785, some of my back-config commits: sr_text/sr_matched sent with sr_err=LDAP_SUCCESS, or related to another error than sr_err. Browsing 2.4.24 patches, an earlier cleanup would have caught #6633 (slapd-bdb error propagation) - my asserts with test047 catch sr_text != NULL when sr_err == 0 - and likely #6629 (freeing controls). -- Regards, Hallvard

1 0

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

19 Jan '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/19/2011 11:39 AM, masarati(a)aero.polimi.it wrote: >> 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. Upgraded to 2.4.23 and the same behavior occurs. I note in issue 6510 that it was suggested that nested mutexes could be used to resolve this. Perhaps we should revisit that. As you can see from our backtrace, this is actually occurring during the processing of ldap_result(). We're handling a rebind as ldap_result travels through a series of referrals. - -- Stephen Gallagher RHCE 804006346421761 Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk03WlYACgkQeiVVYja6o6PiXACgmykXZhhKZkixweJTb/qIVPAc DMAAn2GHK7wu3nC5mkcYq7jI2f13Ql+N =rj7f -----END PGP SIGNATURE-----

1 0

Re: (ITS#5421) slapd vs LDAP_R_COMPILE
by hyc＠symas.com 19 Jan '11

19 Jan '11

h.b.furuseth(a)usit.uio.no wrote: > Taken to this thread: > > http://www.openldap.org/lists/openldap-devel/201011/msg00013.html > librewrite& co vs. logging& ldap-int.h > > Since this ITS now depends on the ldap_debug hack in ldap_log.h, > I'm removing some unnecessary '#include<ldap_log.h>'s for clarity. > I've committed the fix suggested in the email linked above. -- -- 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

(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

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