openldap-bugs

openldap-bugs@openldap.org

1 participants
21065 discussions

Re: (ITS#6511) syncrepl unreliable, stops when master is temporary unreachable
by masarati＠aero.polimi.it 09 Apr '10

09 Apr '10

> Behaviour: > Syncrepl stops working when the master server is temporarily unreachable > or > restarted. > > Expected behaviour: > Retrying to connect indefinatly, once every 10 to 30 seconds. > > Result: > This means we have to restart slapd every time there has been a slight > glitch in > the internet connection. I assume you did not read this <http://www.openldap.org/faq/data/cache/56.html> before filing the bug report. In any case, even assuming the behavior you report is caused by a bug (you are not providing any information that is vaguely useful to this extent), there has been substantial development since 2.4.11, specifically in the area of syncrepl. Unless the issue reproduces in the latest release, there is no point in even starting tracking it down. p.

1 0

(ITS#6511) syncrepl unreliable, stops when master is temporary unreachable
by wilco＠baanhofman.nl 09 Apr '10

09 Apr '10

Full_Name: Wilco Baan Hofman Version: 2.4.11 OS: Debian URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (86.82.223.18) Hi, Behaviour: Syncrepl stops working when the master server is temporarily unreachable or restarted. Expected behaviour: Retrying to connect indefinatly, once every 10 to 30 seconds. Result: This means we have to restart slapd every time there has been a slight glitch in the internet connection. Regards, Wilco Baan Hofman

1 0

Re: (ITS#6510) GSSAPI rebind proc will cause mutex deadlock
by Kurt＠OpenLDAP.org 09 Apr '10

09 Apr '10

On Apr 8, 2010, at 8:08 PM, Howard Chu wrote: > Kurt(a)OpenLDAP.org wrote: >> On Apr 8, 2010, at 3:58 PM, hyc(a)symas.com wrote: >>=20 >>> Sounds like your servers are mis-configured, it is not legal to send = a=3D20=3D >>=20 >>> referral in response to a Bind request. >>=20 >> I note that the technical specification doesn't actually preclude = return =3D >> of a referral in response to a Bind request. However, in practice, = such =3D >> return is quite problematic due to ambiguous semantics and security =3D= >> considerations. >=20 > Right. I can't find the discussion we had about this back in 2004, but = certainly we've already hashed this out in great detail before. >=20 > The fact is that acting on a referral simply means performing a Bind = against some other server. > It does nothing for the authentication state of the session on the = original server. Right, by returning a referral, regardless of how far the client got in = authentication process (including completion of all challenges), the = client is now anonymous at the original server. And there's a security concern, the referral information is not = protected by the underlying authentication mechanism. It is actually = quite possible that this be used by an attacker to cause the client to = try authentication multiple times, possibly with chosen plaintext. I recommend that the library never chase bind referrals. (I tend to = think of rebind as a misfeature. Robust clients really should be using = the async API and carefully managing security contexts and chasing.) -- Kurt=

1 0

Re: (ITS#6510) GSSAPI rebind proc will cause mutex deadlock
by hyc＠symas.com 09 Apr '10

09 Apr '10

Kurt(a)OpenLDAP.org wrote: > On Apr 8, 2010, at 3:58 PM, hyc(a)symas.com wrote: > >> Sounds like your servers are mis-configured, it is not legal to send a=20= > >> referral in response to a Bind request. > > I note that the technical specification doesn't actually preclude return = > of a referral in response to a Bind request. However, in practice, such = > return is quite problematic due to ambiguous semantics and security = > considerations. Right. I can't find the discussion we had about this back in 2004, but certainly we've already hashed this out in great detail before. The fact is that acting on a referral simply means performing a Bind against some other server. It does nothing for the authentication state of the session on the original server. -- -- 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#6510) GSSAPI rebind proc will cause mutex deadlock
by Kurt＠OpenLDAP.org 09 Apr '10

09 Apr '10

On Apr 8, 2010, at 3:58 PM, hyc(a)symas.com wrote: > Sounds like your servers are mis-configured, it is not legal to send a=20= > referral in response to a Bind request. I note that the technical specification doesn't actually preclude return = of a referral in response to a Bind request. However, in practice, such = return is quite problematic due to ambiguous semantics and security = considerations. -- Kurt

1 0

Re: (ITS#6510) GSSAPI rebind proc will cause mutex deadlock
by hyc＠symas.com 08 Apr '10

08 Apr '10

inlovewithGod(a)gmail.com wrote: > Full_Name: Jeremiah Martell > Version: 2.4.21 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (192.146.101.71) > > > I have three windows active directory servers setup: > childA.parent.example.com > parent.example.com > childB.parent.example.com > > I do a LDAP+GSSAPI bind to childA.parent.example.com. > The bind succeeds. > > I do a search that returns referrals, (I know I need to be referred to > parent, and then childB in order to find my result), > and I have openldap follow referrals for me. > > My rebind proc is a function that only calls: > ldap_sasl_interactive_bind_s( ld, NULL, NULL, NULL, NULL, > LDAP_SASL_AUTOMATIC, sasl_driver, params ); > where sasl_driver and params is the same parameters that I used for > the initial bind call to childA. > > After the seach call, the debug looks like this: > >> ldap_chase_v3referrals, where ref[0] = parent.example.com > > myGSSAPIrebindProc > > ldap_sasl_interactive_bind_s > < ldap_sasl_interactive_bind_s > < myGSSAPIrebindProc > < ldap_chase_v3referrals > >> ldap_chase_v3referrals, where ref[0] = childB.parent.example.com > > myGSSAPIrebindProc > > ldap_sasl_interactive_bind_s > > ldap_chase_v3referrals, where ref[0] = childA.parent.example.com > < ldap_chase_v3referrals > > ldap_chase_v3referrals, where ref[0] = > ForestDnsZones.parent.example.com > > myGSSAPIrebindProc > > ldap_sasl_interactive_bind_s ... HANG ON MUTEX > > I changed openldap to make all mutex's recursive, and this fixed my problem. I > was then able to search, chase referrals, bind to referrals with > ldap_sasl_interactive_bind_s, and eventually find my result. Sounds like your servers are mis-configured, it is not legal to send a referral in response to a Bind request. -- -- 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#6507) backglue and paged results issue
by masarati＠aero.polimi.it 08 Apr '10

08 Apr '10

> Ah yes, just saw this. Sorry, my email seems to be slow today (weird). > > Similar to my patch, but I'm unsure about the second part: > > } else if ( op->o_bd != gi->gi_n[0].gn_be ) { > /* if cookie not empty, it's again this database's turn */ > op->o_conn->c_pagedresults_state.ps_be = op->o_bd; > } > > If the cookie is not empty, then it should again be this database's > turn, even it this is this last database. > > This makes a search that stops in the middle of results from last > database with a valid cookie fall back to the first database on > continuation, and thus loop forever. > > Would you consider removing the else if? Well, it's not that simple. The fact is that paged results state is being handled in two ways: when the database is back-bdb/hdb, the cookie is an ID, and it's stored in ps_cookie; otherwise (e.g. back-ldap), it's a berval, stored in ps_cookieval. I need to handle both cases. I think I made it. Now, ps_cookie in c_pagedresults_state is initialized to NOID; back-bdb will set it to 0 first, and then to whatever value it needs. Other backends, that use ps_cookieval, will not touch it. So when ps_cookie == NOID one needs to look at ps_cookieval (and parse it as needed), otherwise ps_cookie suffices. You'll need to update backglue.c, controls.c and back-bdb/search.c. Now it passes all cases I checked, both with local glued databases and with back-null/back-ldap as in your example. p.

1 0

Re: (ITS#6507) backglue and paged results issue
by jonathan＠phillipoux.net 08 Apr '10

08 Apr '10

Le 08/04/2010 15:59, masarati(a)aero.polimi.it a écrit : >> Just one weird case left. Considering the same setup as described above >> (back null with 2 back ldap glued underneath): a search with pagedResults >> and a page size of 3 (the exact number of results returned by each back >> ldap), we get: >> - a first page with the 3 results from back ldap 1 >> - a second page with 3 results from back ldap 2 (so far, so good) >> - but then this last result also has a pagedResults cookie, and the search >> can go on and on, returning the same 2nd page. >> >> Presumably this is related to the patch allowing pagedResults to cross two >> databases. If the first returns an empty cookie (no more results), a new >> cookie is added. However, this should not be done if the last database >> returns no more results. > > It's related to the fact that I need to parse the cookie when it's not > parsed yet, to see whether it's empty. So I'm now parsing it also when > working with the last database, which needs to be treated specially (i.e. > it must let the empty cookie pss thru). Fixed, will commit in a moment. > > Thanks, p. Ah yes, just saw this. Sorry, my email seems to be slow today (weird). Similar to my patch, but I'm unsure about the second part: } else if ( op->o_bd != gi->gi_n[0].gn_be ) { /* if cookie not empty, it's again this database's turn */ op->o_conn->c_pagedresults_state.ps_be = op->o_bd; } If the cookie is not empty, then it should again be this database's turn, even it this is this last database. This makes a search that stops in the middle of results from last database with a valid cookie fall back to the first database on continuation, and thus loop forever. Would you consider removing the else if? Jonathan -- -------------------------------------------------------------- Jonathan Clarke - jonathan(a)phillipoux.net -------------------------------------------------------------- Ldap Synchronization Connector (LSC) - http://lsc-project.org --------------------------------------------------------------

1 0

Re: (ITS#6507) backglue and paged results issue
by masarati＠aero.polimi.it 08 Apr '10

08 Apr '10

> This is a multi-part message in MIME format. > --------------050800080103050407050909 > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > Content-Transfer-Encoding: 8bit > > Le 08/04/2010 13:49, jonathan(a)phillipoux.net a écrit : >> On Wed, 7 Apr 2010 00:54:46 +0200 (CEST), masarati(a)aero.polimi.it wrote: >>>> Le 06/04/2010 20:55, masarati(a)aero.polimi.it a Ã©crit : >>>>> 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. >>>> >>>> Your fix for this problem works well in my tests. >>>> >>>> Under the same subject, another problem arises: >>>> >>>> Consider this : >>>> - back null >>>> ---- back ldap 1 returning 3 results to a search >>>> ---- back ldap 2 returning 3 results to a search >>>> >>>> And you search "back null" with a page size of 2: >>>> - The first response contains 2 results from "back ldap 1" and a >>>> correct >>>> cookie. >>>> - The second response contains 1 result from "back ldap 1" and 1 >>>> result >>>> from "back ldap 2", and another correct cookie. >>>> - The third request, however, goes back to "back ldap 1", and returns >>>> the same results as the first response. >>>> - And so on... forever. >>>> >>>> As I mentioned, it seems that to solve this problem we would have to >>>> tie >>>> a paged results cookie to a particular backend under glue... >>> >>> Should work now. The issue was related to the fact that unless the >>> subordinate backends are local, the response to pgaed results has not >> been >>> parsed into the connection structure... >> >> Yes, much better now. >> >> Just one weird case left. Considering the same setup as described above >> (back null with 2 back ldap glued underneath): a search with >> pagedResults >> and a page size of 3 (the exact number of results returned by each back >> ldap), we get: >> - a first page with the 3 results from back ldap 1 >> - a second page with 3 results from back ldap 2 (so far, so good) >> - but then this last result also has a pagedResults cookie, and the >> search >> can go on and on, returning the same 2nd page. >> >> Presumably this is related to the patch allowing pagedResults to cross >> two >> databases. If the first returns an empty cookie (no more results), a new >> cookie is added. However, this should not be done if the last database >> returns no more results. > > It seems it just needs a simple exception for the last database. The > attached patch works for me. > > Jonathan > -- > -------------------------------------------------------------- > Jonathan Clarke - jonathan(a)phillipoux.net > -------------------------------------------------------------- > Ldap Synchronization Connector (LSC) - http://lsc-project.org > -------------------------------------------------------------- > > --------------050800080103050407050909 > Content-Type: text/x-patch; > name="jcl-backglue-20100408.patch" > Content-Transfer-Encoding: 7bit > Content-Disposition: attachment; > filename="jcl-backglue-20100408.patch" > > Index: servers/slapd/backglue.c > =================================================================== > RCS file: /repo/OpenLDAP/pkg/ldap/servers/slapd/backglue.c,v > retrieving revision 1.153 > diff -a -u -r1.153 backglue.c > --- servers/slapd/backglue.c 6 Apr 2010 20:04:58 -0000 1.153 > +++ servers/slapd/backglue.c 8 Apr 2010 15:39:34 -0000 > @@ -559,6 +559,7 @@ > > /* Check whether the cookie is empty, > * and give remaining databases a chance > + * unless this is already the last database > */ > if ( op->o_bd != gi->gi_n[0].gn_be ) { > int c; > @@ -581,7 +582,7 @@ > tag = ber_scanf( ber, "{im}", &size, &cookie ); > assert( tag != LBER_ERROR ); > > - if ( BER_BVISEMPTY( &cookie ) ) { > + if ( BER_BVISEMPTY( &cookie ) && i != 0 ) { > if ( btmp == b0 ) { > op->o_conn->c_pagedresults_state.ps_be = gi->gi_n[gi->gi_nodes > - 1].gn_be; Yes, thanks. I already fixed it almost the same way. p.

1 0

Re: (ITS#6507) backglue and paged results issue
by jonathan＠phillipoux.net 08 Apr '10

08 Apr '10

This is a multi-part message in MIME format. --------------050800080103050407050909 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Le 08/04/2010 13:49, jonathan(a)phillipoux.net a écrit : > On Wed, 7 Apr 2010 00:54:46 +0200 (CEST), masarati(a)aero.polimi.it wrote: >>> Le 06/04/2010 20:55, masarati(a)aero.polimi.it a Ã©crit : >>>> 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. >>> >>> Your fix for this problem works well in my tests. >>> >>> Under the same subject, another problem arises: >>> >>> Consider this : >>> - back null >>> ---- back ldap 1 returning 3 results to a search >>> ---- back ldap 2 returning 3 results to a search >>> >>> And you search "back null" with a page size of 2: >>> - The first response contains 2 results from "back ldap 1" and a correct >>> cookie. >>> - The second response contains 1 result from "back ldap 1" and 1 result >>> from "back ldap 2", and another correct cookie. >>> - The third request, however, goes back to "back ldap 1", and returns >>> the same results as the first response. >>> - And so on... forever. >>> >>> As I mentioned, it seems that to solve this problem we would have to tie >>> a paged results cookie to a particular backend under glue... >> >> Should work now. The issue was related to the fact that unless the >> subordinate backends are local, the response to pgaed results has not > been >> parsed into the connection structure... > > Yes, much better now. > > Just one weird case left. Considering the same setup as described above > (back null with 2 back ldap glued underneath): a search with pagedResults > and a page size of 3 (the exact number of results returned by each back > ldap), we get: > - a first page with the 3 results from back ldap 1 > - a second page with 3 results from back ldap 2 (so far, so good) > - but then this last result also has a pagedResults cookie, and the search > can go on and on, returning the same 2nd page. > > Presumably this is related to the patch allowing pagedResults to cross two > databases. If the first returns an empty cookie (no more results), a new > cookie is added. However, this should not be done if the last database > returns no more results. It seems it just needs a simple exception for the last database. The attached patch works for me. Jonathan -- -------------------------------------------------------------- Jonathan Clarke - jonathan(a)phillipoux.net -------------------------------------------------------------- Ldap Synchronization Connector (LSC) - http://lsc-project.org -------------------------------------------------------------- --------------050800080103050407050909 Content-Type: text/x-patch; name="jcl-backglue-20100408.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="jcl-backglue-20100408.patch" Index: servers/slapd/backglue.c =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/servers/slapd/backglue.c,v retrieving revision 1.153 diff -a -u -r1.153 backglue.c --- servers/slapd/backglue.c 6 Apr 2010 20:04:58 -0000 1.153 +++ servers/slapd/backglue.c 8 Apr 2010 15:39:34 -0000 @@ -559,6 +559,7 @@ /* Check whether the cookie is empty, * and give remaining databases a chance + * unless this is already the last database */ if ( op->o_bd != gi->gi_n[0].gn_be ) { int c; @@ -581,7 +582,7 @@ tag = ber_scanf( ber, "{im}", &size, &cookie ); assert( tag != LBER_ERROR ); - if ( BER_BVISEMPTY( &cookie ) ) { + if ( BER_BVISEMPTY( &cookie ) && i != 0 ) { if ( btmp == b0 ) { op->o_conn->c_pagedresults_state.ps_be = gi->gi_n[gi->gi_nodes - 1].gn_be; --------------050800080103050407050909--

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