openldap-bugs April 2010

openldap-bugs@openldap.org

45 participants
233 discussions

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

Re: (ITS#6508) memberof segmentation fault
by masarati＠aero.polimi.it 08 Apr '10

08 Apr '10

Fixed in HEAD; please check. a_numvals was added in September 2007 (slap.h 1.831 Fri Sep 21 06:43:56 2007); slapo-memberof.c was first committed in August 2007 (memberof.c 1.1 Fri Aug 24 00:46:58 2007), but developed about one year earlier. I'm surprised it survived so long without the a_numvals bit :) Thanks, p.

1 0

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

08 Apr '10

> 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.

1 0

(ITS#6510) GSSAPI rebind proc will cause mutex deadlock
by inlovewithGod＠gmail.com 08 Apr '10

08 Apr '10

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. Thanks, - Jeremiah

1 0

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

08 Apr '10

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. Jonathan

1 0

(ITS#6509) slapo-memberof follow cascading group membership
by sspreitzer＠ch.ibm.com 08 Apr '10

08 Apr '10

Full_Name: Sascha Thomas Spreitzer Version: 2.4.21 OS: Linux RHEL 5.4 ppc64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (195.212.29.179) Dear openldap developers and maintainers of the memberof feature, it would be great if you could implement a cascading group membership functionality. Like say a group can be part of a group and those members will be listed respectively. Thank you very much in advance, yours sincerely, Sascha Thomas Spreitzer IBM Switzerland - unix engineering Fedora Project Ambassador

1 0

TLS issues
by Daniel Gomes 07 Apr '10

07 Apr '10

Dear list members, I am having some problems with TLS I would like to share and hopefully solve with your help. First of all, the specs: it's a OpenLDAP 2.4.19 compiled (manually, not via apt-get) on a Ubuntu 8.04 (Hardy). I don't think it matters, but I am using the dynlist overlay (that's why I had to compile manually and not via apt-get, as I couldn't get it to work with the package Ubuntu provides). Passing on to the problem itself, let me just start by saying that the SSL/TLS setup itself seems to be working fine, and I am always able to ldapsearch on port 636 with ldaps:// (SSL) or on port 389 with ldap:// and -ZZ (TLS). Unfortunately, using other clients (phpLDAPadmin and some custom php scripts I wrote), the behavior is rather random. Sometimes it fails, sometimes it works (at the beginning it worked more often than not, lately it has been working less and less). The server logs, unfortunately, are not so helpful (for me, at least!). The only error I see (with logs at -1, trying to connect via phpLDAPadmin with TLS on port 389) is: connection_read(15): TLS accept failure error=-1 id=23, closing Apr 7 16:45:18 gold slapd[7385]: connection_closing: readying conn=23 sd=15 for close Apr 7 16:45:18 gold slapd[7385]: connection_close: conn=23 sd=15 Apr 7 16:45:18 gold slapd[7385]: daemon: removing 15 Apr 7 16:45:18 gold slapd[7385]: daemon: activity on 1 descriptor Apr 7 16:45:18 gold slapd[7385]: daemon: activity on: Apr 7 16:45:18 gold slapd[7385]: conn=23 fd=15 closed (TLS negotiation failure) Trying on port 636 with ldaps:// yields the same error. But as I mentioned, it just happen sometimes, while on others the connection is successfully established! Although I did notice that even when it does work, I get the following error: connection_read(14): unable to get TLS client DN, error=49 id=8 but it is quickly followed by a "conn=8 fd=14 TLS established tls_ssf=256 ssf=256"... So, this is my problem and it is getting me quite puzzled... The fact that it does work on occasion makes me think it can't be my configuration or the usual file permission culprit... Here's my slapd.conf (I removed the ACL configuration, as I am guessing it's not important here): # # See slapd.conf(5) for details on configuration options. # This file should NOT be world readable. # include /usr/local/etc/openldap/schema/core.schema include /usr/local/etc/openldap/schema/cosine.schema include /usr/local/etc/openldap/schema/dyngroup.schema include /usr/local/etc/openldap/schema/inetorgperson.schema #Custom Schemas include /usr/local/etc/openldap/schema/local.schema include /usr/local/etc/openldap/schema/postfix.schema pidfile /home/slapd/run/slapd.pid argsfile /home/slapd/run/slapd.args ####################################################################### # Database definitions ####################################################################### database hdb suffix "dc=example,dc=com" rootdn "cn=admin,dc=example,dc=com" rootpw secret directory /home/slapd/database index objectClass eq ####################################################################### # Replication ####################################################################### overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 ####################################################################### # TLS ####################################################################### TLSCipherSuite HIGH:MEDIUM:+SSLv2 TLSCACertificateFile /home/slapd/ssl/cacert.pem TLSCertificateFile /home/slapd/ssl/servercrt.pem TLSCertificateKeyFile /home/slapd/ssl/serverkey.pem TLSVerifyClient never ####################################################################### # Overlay (for dynamic lists) ####################################################################### overlay dynlist dynlist-attrset ipfnRole memberURL member If it helps for anything, in the ldap.conf files of the client I also have the "TLS_REQCERT never" setting, together with the TLS_CACERT and TLS_CACERTDIR for the CA's certificate. Thanks in advance for any help, -- Daniel Gomes (SysAdmin) dgomes(a)ipfn.ist.utl.pt Ext. 3487 - 218419487 Instituto de Plasmas e usão Nuclear Instituto Superior Técnico - UTL Av. Rovisco Pais - 1049-001 Lisboa - Portugal

2 1

(ITS#6508) memberof segmentation fault
by ndunbar＠llnw.com 07 Apr '10

07 Apr '10

Full_Name: Neil Dunbar Version: 2.4.21 OS: Debian 5, Ubuntu 9.10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (68.142.115.87) Hi there, It looks like there's a small bug in memberof.c - it only manifests itself when "memberof_dangling" is set to "drop". I think that, while the overlay reduces the a->a_vals and a->a_nvals array by one, to strip out a non-existent DN, it needs to reduce the a->a_numvals variable as well. The end result of this is that if one adds a group which has a mix of members which exist in the DIT, and some which don't, the entry_encode() routing will segfault. [I can only reproduce the segv in back-bdb and back-hdb. back-ldif doesn't seem to exhibit this behaviour]. I've uploaded a tiny slapd.conf and test LDIF file (in ftp://ftp.openldap.org/incoming/memberof-segv-20100407.tar.gz) which is normally enough to trigger the fault. If one starts up slapd via slapd -f mof-slapd.conf -h ldap://localhost -d trace followed by ldapmodify -x -H ldap://localhost -D cn=admin,dc=test -w adminpw -f ldif/test-memberof.ldif one should see an assertion fail in entry_encode() with (i == a->a_numvals) failing. The following patch seems to fix it, but I haven't done real regression testing to see if it rolls other errors. The normal slapd unit tests seem to yield proper results though. ---8<----8<------ --- memberof.c.orig 2010-04-07 16:49:44.000000000 -0700 +++ memberof.c 2010-04-07 16:49:20.000000000 -0700 @@ -580,6 +580,7 @@ sizeof( struct berval ) * ( j - i ) ); } i--; + a->a_numvals--; } } ---8<----8<------ Hope this helps, Neil

1 0

← Newer
1
...
17
18
19
20
21
22
23
24
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs April 2010