openldap-bugs July 2011

openldap-bugs@openldap.org

23 participants
60 discussions

(ITS#6997) Segmentation fault when using slapo-rwm and slapo-chain
by mgaupp＠googlemail.com 19 Jul '11

19 Jul '11

Full_Name: Manuel Gaupp Version: 2.4.26 OS: Linux 2.6.18 (CentOS 5.6 x86_64) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (93.208.112.253) Under the following circumstances OpenLDAP crashes when a chained search does not return with result code 0: - "rwm" overlay used in a global context - "chain" overlay used in a database specifix context (gdb) bt #0 0x0000000400040004 in ?? () #1 0x000000000042e5c7 in slap_cleanup_play (op=0x197834b0, rs=0x42a07ca0) at result.c:539 #2 0x000000000042ef9b in send_ldap_response (op=0x197834b0, rs=0x42a07ca0) at result.c:724 #3 0x000000000042fcf9 in slap_send_ldap_result (op=0x197834b0, rs=0x42a07ca0) at result.c:851 #4 0x00000000004d982a in ldap_chain_response (op=0x197834b0, rs=0x42a07ca0) at chain.c:1165 #5 0x00000000004820ca in over_back_response (op=0x197834b0, rs=0x42a07ca0) at backover.c:237 #6 0x000000000042e535 in slap_response_play (op=0x197834b0, rs=0x42a07ca0) at result.c:505 #7 0x000000000042ef78 in send_ldap_response (op=0x197834b0, rs=0x42a07ca0) at result.c:579 #8 0x000000000042fcf9 in slap_send_ldap_result (op=0x197834b0, rs=0x42a07ca0) at result.c:851 #9 0x00000000004928f0 in bdb_search (op=0x197834b0, rs=0x42a07ca0) at search.c:499 #10 0x0000000000482352 in overlay_op_walk (op=0x197834b0, rs=0x42a07ca0, which=op_search, oi=0x196f3bb0, on=0x0) at backover.c:671 #11 0x00000000004828b7 in over_op_func (op=0x197834b0, rs=0x42a07ca0, which=op_search) at backover.c:723 #12 0x0000000000421cf9 in fe_op_search (op=0x197834b0, rs=0x42a07ca0) at search.c:402 #13 0x0000000000482352 in overlay_op_walk (op=0x197834b0, rs=0x42a07ca0, which=op_search, oi=0x1970fd30, on=0x0) at backover.c:671 #14 0x00000000004828b7 in over_op_func (op=0x197834b0, rs=0x42a07ca0, which=op_search) at backover.c:723 #15 0x0000000000422505 in do_search (op=0x197834b0, rs=0x42a07ca0) at search.c:247 #16 0x000000000041fa95 in connection_operation (ctx=0x42a07d70, arg_v=<value optimized out>) at connection.c:1138 #17 0x0000000000503d5c in ldap_int_thread_pool_wrapper (xpool=0x196beee0) at tpool.c:685 #18 0x000000316820673d in start_thread () from /lib64/libpthread.so.0 #19 0x0000003167ad44bd in clone () from /lib64/libc.so.6 OpenLDAP 2.4.26 was built using: ./configure --enable-rewrite --enable-ldap --enable-rwm --enable-bdb This issue can be reproduced using the following configuration (referred as 'slapd.conf.proxy') ------------------------------------------ overlay rwm # There might be some rewrite directives database bdb suffix "o=example" rootdn "cn=admin,o=example" rootpw secret directory /root/db.proxy overlay chain chain-return-error true chain-uri "ldap://localhost:38977" ------------------------------------------ The process is started on port 389 with plain ldap /usr/local/libexec/slapd -f slapd.conf.proxy -h "ldap://localhost:389" Create the following entry in this server: dn: cn=ldap,o=example objectclass: extensibleObject objectclass: referral ref: ldap://localhost:38977/cn=real,o=example To reproduce the error there has to be another server where the referral points to. It contains the following minimal configuration: (referred as 'slapd.conf.server') ------------------------------------------ database bdb suffix "cn=real,o=example" rootdn "cn=admin,cn=real,o=example" rootpw secret directory /root/db.server ------------------------------------------ The process is started on port 38977 with plain ldap /usr/local/libexec/slapd -f slapd.conf.server -h "ldap://localhost:38977" Using the following ldapsearch, slapd crashes: ldapsearch -h localhost -p 389 -D "cn=admin,o=example" -w secret \ -x -b "ou=abc,cn=ldap,o=example" 1.1 Whereas the following ldapsearch returns with "success" ldapsearch -h localhost -p 389 -D "cn=admin,o=example" -w secret \ -x -b "cn=ldap,o=example" 1.1 Deactivating the "rwm" overlay prevents from this issue. So I think the problem can be found somewhere in the rwm sources. -- Manuel

1 0

RE: (ITS#6985) sssvlv / greaterThanOrEqual problem
by ctcard＠hotmail.com 18 Jul '11

18 Jul '11

> ctcard(a)hotmail.com wrote: > > Full_Name: Chris Card > > Version: HEAD (on 30 June 2011) > > OS: Centos 5.4 > > URL: ftp://ftp.openldap.org/incoming/ > > Submission from: (NULL) (91.194.158.133) > > > > > > I am running slapd built from HEAD on June 30th 2011, with back-sql backend, and > > pcache and sssvlv overlays. > > > > I am submitting a search request with vlv and sort controls. > > > > In the sort control I am specifying attributeType cn and orderingRule > > caseIgnoreOrderingMatch. > > > > If I specify 'd' as the greaterThanOrEqual value of the vlv control, beforeCount > > 0 and afterCount 4, I get 5 entries with the following cns returned: > > > > Dave Smith > > Fiona Smith > > Glynis Smith > > Jane Smith > > Jennifer Smith > > > > If I specify 'g' in greaterThanOrEqual I get: > > > > Glynis Smith > > Jane Smith > > Jennifer Smith > > Jim Smith > > Mark Smith > > > > But if I specify 'f' I get no entries returned. > > Now fixed in git master. > Thanks, I've tried that fix and it works (and is simpler than my suggestion). Chris

1 0

RE: (ITS#6985) sssvlv / greaterThanOrEqual problem
by ctcard＠hotmail.com 18 Jul '11

18 Jul '11

> > > >>>>>> Looking at the code in sssvlv.c, it uses tavl_find3() to search the values, but the > >>>>>> code in tavl_find3() looks to me that it only works properly with an exact match > >>>>>> type of matching rule: > >>>>>> > >>>>>> Avlnode * > >>>>>> tavl_find3( Avlnode *root, const void *data, AVL_CMP fcmp, int *ret ) > >>>>>> { > >>>>>> int cmp = -1, dir; > >>>>>> Avlnode *prev = root; > >>>>>> > >>>>>> while ( root != 0&& (cmp = (*fcmp)( data, root->avl_data )) != 0 ) { > >>>>>> prev = root; > >>>>>> dir = cmp> 0; > >>>>>> root = avl_child( root, dir ); > >>>>>> } > >>>>>> *ret = cmp; > >>>>>> return root ? root : prev; > >>>>>> } > >>>>>> > >>>>>> since the while loop terminates when the fcmp function returns 0 (i.e. exact match). > >>>>>> > >>>>> > >>>>> I think I've worked out where the problem is. > >>>>> Firstly, there's a comment before tavl_find3() saying > >>>>> /* > >>>>> * tavl_find2 - returns Avlnode instead of data pointer. > >>>>> * tavl_find3 - as above, but returns Avlnode even if no match is found. > >>>>> * also set *ret = last comparison result, or -1 if root == NULL. > >>>>> */ > >>>>> > >>>>> but the "or -1 if root == NULL" is not done. > >> > >> Not true; since cmp is initialized to -1, it will return -1 when the function > >> is entered with root == NULL. There is no bug in this part.It depends how you read the comment. > > I wrote the code and the comment; it does what I intended it to do. There is > no "depends" about it. The comment is ambiguous, but in any case the code as it stands doesn't work with the way tavl_find3() is called in sssvlv.c.For example:if cmp > 0 when the while loop terminates, the sssvlv code treats that as if the search failed, whereas the search oughtto return the closest node > search node. My suggested patch does work with the way tavl_find3() is called in sssvlv.c, but I'd be happy with adding a new function, tavl_find4() say, to implement this functionality. In that case I'd suggest it look like this: Avlnode *tavl_find4( Avlnode *root, const void *data, AVL_CMP fcmp){ int cmp, dir; Avlnode *prev = root; Avlnode *prev_gt = 0; while ( root != 0 && (cmp = (*fcmp)( data, root->avl_data )) != 0 ) { prev = root; dir = cmp > 0; prev_gt = (dir ? prev_gt : root); root = avl_child( root, dir ); } return (root ? root : (prev_gt ? prev_gt : prev));} tavl_find4() always returns the first node >= the search node, unless the search node is > all the nodes in the tree, in which case the last node is returned (or null if the tree is empty). Then replace cur_node = tavl_find3( so->so_tree, sn, node_cmp, &j ); /* didn't find >= match */ if ( j > 0 ) cur_node = NULL;by cur_node = tavl_find4( so->so_tree, sn, node_cmp); in sssvlv.c. Chris

1 0

Re: (ITS#6985) sssvlv / greaterThanOrEqual problem
by hyc＠symas.com 18 Jul '11

18 Jul '11

ctcard(a)hotmail.com wrote: > Full_Name: Chris Card > Version: HEAD (on 30 June 2011) > OS: Centos 5.4 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (91.194.158.133) > > > I am running slapd built from HEAD on June 30th 2011, with back-sql backend, and > pcache and sssvlv overlays. > > I am submitting a search request with vlv and sort controls. > > In the sort control I am specifying attributeType cn and orderingRule > caseIgnoreOrderingMatch. > > If I specify 'd' as the greaterThanOrEqual value of the vlv control, beforeCount > 0 and afterCount 4, I get 5 entries with the following cns returned: > > Dave Smith > Fiona Smith > Glynis Smith > Jane Smith > Jennifer Smith > > If I specify 'g' in greaterThanOrEqual I get: > > Glynis Smith > Jane Smith > Jennifer Smith > Jim Smith > Mark Smith > > But if I specify 'f' I get no entries returned. Now fixed in git master. -- -- 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#6985) sssvlv / greaterThanOrEqual problem
by hyc＠symas.com 18 Jul '11

18 Jul '11

Chris Card wrote: > >>>>>> Looking at the code in sssvlv.c, it uses tavl_find3() to search the values, but the >>>>>> code in tavl_find3() looks to me that it only works properly with an exact match >>>>>> type of matching rule: >>>>>> >>>>>> Avlnode * >>>>>> tavl_find3( Avlnode *root, const void *data, AVL_CMP fcmp, int *ret ) >>>>>> { >>>>>> int cmp = -1, dir; >>>>>> Avlnode *prev = root; >>>>>> >>>>>> while ( root != 0&& (cmp = (*fcmp)( data, root->avl_data )) != 0 ) { >>>>>> prev = root; >>>>>> dir = cmp> 0; >>>>>> root = avl_child( root, dir ); >>>>>> } >>>>>> *ret = cmp; >>>>>> return root ? root : prev; >>>>>> } >>>>>> >>>>>> since the while loop terminates when the fcmp function returns 0 (i.e. exact match). >>>>>> >>>>> >>>>> I think I've worked out where the problem is. >>>>> Firstly, there's a comment before tavl_find3() saying >>>>> /* >>>>> * tavl_find2 - returns Avlnode instead of data pointer. >>>>> * tavl_find3 - as above, but returns Avlnode even if no match is found. >>>>> * also set *ret = last comparison result, or -1 if root == NULL. >>>>> */ >>>>> >>>>> but the "or -1 if root == NULL" is not done. >> >> Not true; since cmp is initialized to -1, it will return -1 when the function >> is entered with root == NULL. There is no bug in this part.It depends how you read the comment. I wrote the code and the comment; it does what I intended it to do. There is no "depends" about it. -- -- 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#6985) sssvlv / greaterThanOrEqual problem
by ctcard＠hotmail.com 18 Jul '11

18 Jul '11

> >>>> Looking at the code in sssvlv.c, it uses tavl_find3() to search the values, but the > >>>> code in tavl_find3() looks to me that it only works properly with an exact match > >>>> type of matching rule: > >>>> > >>>> Avlnode * > >>>> tavl_find3( Avlnode *root, const void *data, AVL_CMP fcmp, int *ret ) > >>>> { > >>>> int cmp = -1, dir; > >>>> Avlnode *prev = root; > >>>> > >>>> while ( root != 0&& (cmp = (*fcmp)( data, root->avl_data )) != 0 ) { > >>>> prev = root; > >>>> dir = cmp> 0; > >>>> root = avl_child( root, dir ); > >>>> } > >>>> *ret = cmp; > >>>> return root ? root : prev; > >>>> } > >>>> > >>>> since the while loop terminates when the fcmp function returns 0 (i.e. exact match). > >>>> > >>> > >>> I think I've worked out where the problem is. > >>> Firstly, there's a comment before tavl_find3() saying > >>> /* > >>> * tavl_find2 - returns Avlnode instead of data pointer. > >>> * tavl_find3 - as above, but returns Avlnode even if no match is found. > >>> * also set *ret = last comparison result, or -1 if root == NULL. > >>> */ > >>> > >>> but the "or -1 if root == NULL" is not done. > > Not true; since cmp is initialized to -1, it will return -1 when the function > is entered with root == NULL. There is no bug in this part.It depends how you read the comment. If the function is *entered* with root == NULL, then I agree that -1 is returned, but if the while loop exits with root == NULL then the last comparison result is returned, which causes problems to the call in sssvlv.c.> > >>> Secondly, if no exact match is found, prev is returned which may point to a node which is less than the search > >>> node, depending on what the tree looks like, but we really want a pointer to the last node which was greater than > >>> the search node to be returned. > >>> > >>> Once these fixes are done, the correct node is returned by tavl_find3 to the call in send_list() in sssvlv.c (line 523). > > This fix is also not correct. Possibly tavl_find3() has been misused in the > sssvlv code, but this function works as designed. >Possibly. But with the patch as suggested, the sssvlv code works correctly and gets the correct node.If you think these changes might break other uses of tavl_find3() (of which there didn't seem to be many), perhapstavl_find4() could be added. > >>> There is another bug in send_list() in sssvlv.c, at lines 535-544: > >>> > >>> if ( i> 0 ) { > >>> tmp_node = tavl_end(so->so_tree, TAVL_DIR_RIGHT); > >>> dir = TAVL_DIR_LEFT; > >>> } else { > >>> tmp_node = tavl_end(so->so_tree, TAVL_DIR_LEFT); > >>> dir = TAVL_DIR_RIGHT; > >>> } > >>> for (i=0; tmp_node != cur_node; > >>> tmp_node = tavl_next( tmp_node, dir ), i++); > >>> so->so_vlv_target = i; > >>> This code is ok if the cur_node is in the left hand side of the tree, but if it is in the rhs of the tree so_vlv_target is set > >>> to an offset from the end of the list, rather than the beginning. > > OK, looks like you have a good patch for this. > > >> One more issue: the most recent draft spec for vlv (http://tools.ietf.org/html/draft-ietf-ldapext-ldapv3-vlv-09) states that the offset field in the vlv request has range 1..maxInt whereas the targetPosition in the vlv response has range 0..maxInt. > >> > >> However, my interpretation of the spec is that offset and targetPosition represent the same thing, i.e. the position of the target entry in the list, with the first entry having offset/targetPosition = 1. > >> > >> If that interpretation is correct, the assignment of so_vlv_target in the code above is off by one, since i will be zero if cur_node is at the beginning of the list. > >> > > > > I've uploaded a patch to ftp.openldap.org, incoming/Chris-Card-110708.ITS-6985-fix.patch

1 0

Re: (ITS#6985) sssvlv / greaterThanOrEqual problem
by hyc＠symas.com 18 Jul '11

18 Jul '11

ctcard(a)hotmail.com wrote: >>>> Looking at the code in sssvlv.c, it uses tavl_find3() to search the values, but the >>>> code in tavl_find3() looks to me that it only works properly with an exact match >>>> type of matching rule: >>>> >>>> Avlnode * >>>> tavl_find3( Avlnode *root, const void *data, AVL_CMP fcmp, int *ret ) >>>> { >>>> int cmp = -1, dir; >>>> Avlnode *prev = root; >>>> >>>> while ( root != 0&& (cmp = (*fcmp)( data, root->avl_data )) != 0 ) { >>>> prev = root; >>>> dir = cmp> 0; >>>> root = avl_child( root, dir ); >>>> } >>>> *ret = cmp; >>>> return root ? root : prev; >>>> } >>>> >>>> since the while loop terminates when the fcmp function returns 0 (i.e. exact match). >>>> >>> >>> I think I've worked out where the problem is. >>> Firstly, there's a comment before tavl_find3() saying >>> /* >>> * tavl_find2 - returns Avlnode instead of data pointer. >>> * tavl_find3 - as above, but returns Avlnode even if no match is found. >>> * also set *ret = last comparison result, or -1 if root == NULL. >>> */ >>> >>> but the "or -1 if root == NULL" is not done. Not true; since cmp is initialized to -1, it will return -1 when the function is entered with root == NULL. There is no bug in this part. >>> Secondly, if no exact match is found, prev is returned which may point to a node which is less than the search >>> node, depending on what the tree looks like, but we really want a pointer to the last node which was greater than >>> the search node to be returned. >>> >>> Once these fixes are done, the correct node is returned by tavl_find3 to the call in send_list() in sssvlv.c (line 523). This fix is also not correct. Possibly tavl_find3() has been misused in the sssvlv code, but this function works as designed. >>> There is another bug in send_list() in sssvlv.c, at lines 535-544: >>> >>> if ( i> 0 ) { >>> tmp_node = tavl_end(so->so_tree, TAVL_DIR_RIGHT); >>> dir = TAVL_DIR_LEFT; >>> } else { >>> tmp_node = tavl_end(so->so_tree, TAVL_DIR_LEFT); >>> dir = TAVL_DIR_RIGHT; >>> } >>> for (i=0; tmp_node != cur_node; >>> tmp_node = tavl_next( tmp_node, dir ), i++); >>> so->so_vlv_target = i; >>> This code is ok if the cur_node is in the left hand side of the tree, but if it is in the rhs of the tree so_vlv_target is set >>> to an offset from the end of the list, rather than the beginning. OK, looks like you have a good patch for this. >> One more issue: the most recent draft spec for vlv (http://tools.ietf.org/html/draft-ietf-ldapext-ldapv3-vlv-09) states that the offset field in the vlv request has range 1..maxInt whereas the targetPosition in the vlv response has range 0..maxInt. >> >> However, my interpretation of the spec is that offset and targetPosition represent the same thing, i.e. the position of the target entry in the list, with the first entry having offset/targetPosition = 1. >> >> If that interpretation is correct, the assignment of so_vlv_target in the code above is off by one, since i will be zero if cur_node is at the beginning of the list. >> > > I've uploaded a patch to ftp.openldap.org, incoming/Chris-Card-110708.ITS-6985-fix.patch > > Chris -- -- 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#6985) sssvlv / greaterThanOrEqual problem
by ctcard＠hotmail.com 16 Jul '11

16 Jul '11

[And this time in plain text ...][I thought I'd send this to the ITS list, but I only sent it to myself :-( ] > > > > > > > > > > I am running slapd built from HEAD on June 30th 2011, with back-sql > > > > > > > > Can you confirm this issue with another backend, e.g. back-bdb? Bugs > > > > specific to back-sql or to interaction with it could receive only marginal > > > > attention. > > > > > > > > p. > > > > > > > > > > I've imported my data into a server with a bdb backend, and I see the same problem. > > > > > > Looking at the code in sssvlv.c, it uses tavl_find3() to search the values, but the > > > code in tavl_find3() looks to me that it only works properly with an exact match > > > type of matching rule: > > > > > > Avlnode * > > > tavl_find3( Avlnode *root, const void *data, AVL_CMP fcmp, int *ret ) > > > { > > > int cmp = -1, dir; > > > Avlnode *prev = root; > > > > > > while ( root != 0 && (cmp = (*fcmp)( data, root->avl_data )) != 0 ) { > > > prev = root; > > > dir = cmp > 0; > > > root = avl_child( root, dir ); > > > } > > > *ret = cmp; > > > return root ? root : prev; > > > } > > > > > > since the while loop terminates when the fcmp function returns 0 (i.e. exact match). > > > > > > > I think I've worked out where the problem is. > > Firstly, there's a comment before tavl_find3() saying > > /* > > * tavl_find2 - returns Avlnode instead of data pointer. > > * tavl_find3 - as above, but returns Avlnode even if no match is found. > > * also set *ret = last comparison result, or -1 if root == NULL. > > */ > > > > but the "or -1 if root == NULL" is not done. > > > > Secondly, if no exact match is found, prev is returned which may point to a node which is less than the search > > node, depending on what the tree looks like, but we really want a pointer to the last node which was greater than > > the search node to be returned. > > > > Once these fixes are done, the correct node is returned by tavl_find3 to the call in send_list() in sssvlv.c (line 523). > > > > There is another bug in send_list() in sssvlv.c, at lines 535-544: > > > > if ( i > 0 ) { > > tmp_node = tavl_end(so->so_tree, TAVL_DIR_RIGHT); > > dir = TAVL_DIR_LEFT; > > } else { > > tmp_node = tavl_end(so->so_tree, TAVL_DIR_LEFT); > > dir = TAVL_DIR_RIGHT; > > } > > for (i=0; tmp_node != cur_node; > > tmp_node = tavl_next( tmp_node, dir ), i++); > > so->so_vlv_target = i; > > This code is ok if the cur_node is in the left hand side of the tree, but if it is in the rhs of the tree so_vlv_target is set > > to an offset from the end of the list, rather than the beginning. > > > > One more issue: the most recent draft spec for vlv (http://tools.ietf.org/html/draft-ietf-ldapext-ldapv3-vlv-09) states that the offset field in the vlv request has range 1..maxInt whereas the targetPosition in the vlv response has range 0..maxInt. > > However, my interpretation of the spec is that offset and targetPosition represent the same thing, i.e. the position of the target entry in the list, with the first entry having offset/targetPosition = 1. > > If that interpretation is correct, the assignment of so_vlv_target in the code above is off by one, since i will be zero if cur_node is at the beginning of the list. > I've uploaded a patch to ftp.openldap.org, incoming/Chris-Card-110708.ITS-6985-fix.patch Chris

1 0

RE: (ITS#6985) sssvlv / greaterThanOrEqual problem
by ctcard＠hotmail.com 16 Jul '11

16 Jul '11

--_3d71bf45-bf8f-4026-9c30-d39291bf9f56_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [I thought I'd send this to the ITS list=2C but I only sent it to myself :-= ( ] > > > > > > > > > > I am running slapd built from HEAD on June 30th 2011=2C with back= -sql > > > > > > > > Can you confirm this issue with another backend=2C e.g. back-bdb? B= ugs > > > > specific to back-sql or to interaction with it could receive only m= arginal > > > > attention. > > > > > > > > p. > > > > > > > > > > I've imported my data into a server with a bdb backend=2C and I see t= he same problem. > > > > > > Looking at the code in sssvlv.c=2C it uses tavl_find3() to search the= values=2C but the > > > code in tavl_find3() looks to me that it only works properly with an = exact match > > > type of matching rule: > > > > > > Avlnode * > > > tavl_find3( Avlnode *root=2C const void *data=2C AVL_CMP fcmp=2C int = *ret ) > > > { > > > int cmp =3D -1=2C dir=3B > > > Avlnode *prev =3D root=3B > > > > > > while ( root !=3D 0 && (cmp =3D (*fcmp)( data=2C root->avl_data )) != =3D 0 ) { > > > prev =3D root=3B > > > dir =3D cmp > 0=3B > > > root =3D avl_child( root=2C dir )=3B > > > } > > > *ret =3D cmp=3B > > > return root ? root : prev=3B > > > } > > > > > > since the while loop terminates when the fcmp function returns 0 (i.e= . exact match). > > > > > > > I think I've worked out where the problem is. > > Firstly=2C there's a comment before tavl_find3() saying > > /* > > * tavl_find2 - returns Avlnode instead of data pointer. > > * tavl_find3 - as above=2C but returns Avlnode even if no match is foun= d. > > * also set *ret =3D last comparison result=2C or -1 if root =3D=3D NULL= . > > */ > > > > but the "or -1 if root =3D=3D NULL" is not done. > > > > Secondly=2C if no exact match is found=2C prev is returned which may po= int to a node which is less than the search > > node=2C depending on what the tree looks like=2C but we really want a p= ointer to the last node which was greater than > > the search node to be returned. > > > > Once these fixes are done=2C the correct node is returned by tavl_find3= to the call in send_list() in sssvlv.c (line 523). > > > > There is another bug in send_list() in sssvlv.c=2C at lines 535-544: > > > > if ( i > 0 ) { > > tmp_node =3D tavl_end(so->so_tree=2C TAVL_DIR_RIGHT)=3B > > dir =3D TAVL_DIR_LEFT=3B > > } else { > > tmp_node =3D tavl_end(so->so_tree=2C TAVL_DIR_LEFT)=3B > > dir =3D TAVL_DIR_RIGHT=3B > > } > > for (i=3D0=3B tmp_node !=3D cur_node=3B > > tmp_node =3D tavl_next( tmp_node=2C dir )=2C i++)=3B > > so->so_vlv_target =3D i=3B > > This code is ok if the cur_node is in the left hand side of the tree=2C= but if it is in the rhs of the tree so_vlv_target is set > > to an offset from the end of the list=2C rather than the beginning. > > > > One more issue: the most recent draft spec for vlv (http://tools.ietf.org= /html/draft-ietf-ldapext-ldapv3-vlv-09) states that the offset field in the= vlv request has range 1..maxInt whereas the targetPosition in the vlv resp= onse has range 0..maxInt. > > However=2C my interpretation of the spec is that offset and targetPositio= n represent the same thing=2C i.e. the position of the target entry in the = list=2C with the first entry having offset/targetPosition =3D 1. > > If that interpretation is correct=2C the assignment of so_vlv_target in t= he code above is off by one=2C since i will be zero if cur_node is at the b= eginning of the list. > I've uploaded a patch to ftp.openldap.org=2C incoming/Chris-Card-110708.ITS= -6985-fix.patch Chris = --_3d71bf45-bf8f-4026-9c30-d39291bf9f56_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <html> <head> <style></style> </head> <body class=3D'hmmessage'><div dir=3D'ltr'> [I thought I'd send this to the ITS list=2C but I only sent it to myself :-= ( ] <div> &gt=3B &gt=3B &gt=3B &gt=3B &gt=3B &gt=3B &gt=3B &gt= =3B &gt=3B &gt=3B I am running slapd built from HEAD on June 30th 2011=2C w= ith back-sql &gt=3B &gt=3B &gt=3B &gt=3B &gt=3B &gt=3B &gt=3B &gt=3B = Can you confirm this issue with another backend=2C e.g. back-bdb? Bugs &= gt=3B &gt=3B &gt=3B &gt=3B specific to back-sql or to interaction with it c= ould receive only marginal &gt=3B &gt=3B &gt=3B &gt=3B attention. &gt= =3B &gt=3B &gt=3B &gt=3B &gt=3B &gt=3B &gt=3B &gt=3B p. &gt=3B &gt=3B= &gt=3B &gt=3B &gt=3B &gt=3B &gt=3B &gt=3B &gt=3B &gt=3B I've importe= d my data into a server with a bdb backend=2C and I see the same problem.<b= r>&gt=3B &gt=3B &gt=3B &gt=3B &gt=3B &gt=3B Looking at the code in sssvl= v.c=2C it uses tavl_find3() to search the values=2C but the &gt=3B &gt= =3B &gt=3B code in tavl_find3() looks to me that it only works properly wit= h an exact match &gt=3B &gt=3B &gt=3B type of matching rule: &gt=3B &= gt=3B &gt=3B &gt=3B &gt=3B &gt=3B Avlnode * &gt=3B &gt=3B &gt=3B tavl= _find3( Avlnode *root=2C const void *data=2C AVL_CMP fcmp=2C int *ret ) = &gt=3B &gt=3B &gt=3B { &gt=3B &gt=3B &gt=3B int cmp =3D -1=2C dir=3B = &gt=3B &gt=3B &gt=3B Avlnode *prev =3D root=3B &gt=3B &gt=3B &gt=3B &= gt=3B &gt=3B &gt=3B while ( root !=3D 0 &amp=3B&amp=3B (cmp =3D (*fcmp)( da= ta=2C root-&gt=3Bavl_data )) !=3D 0 ) { &gt=3B &gt=3B &gt=3B prev =3D ro= ot=3B &gt=3B &gt=3B &gt=3B dir =3D cmp &gt=3B 0=3B &gt=3B &gt=3B &gt= =3B root =3D avl_child( root=2C dir )=3B &gt=3B &gt=3B &gt=3B } &gt= =3B &gt=3B &gt=3B *ret =3D cmp=3B &gt=3B &gt=3B &gt=3B return root ? roo= t : prev=3B &gt=3B &gt=3B &gt=3B } &gt=3B &gt=3B &gt=3B &gt=3B &gt= =3B &gt=3B since the while loop terminates when the fcmp function returns 0= (i.e. exact match). &gt=3B &gt=3B &gt=3B &gt=3B &gt=3B &gt=3B &gt= =3B I think I've worked out where the problem is. &gt=3B &gt=3B Firstly= =2C there's a comment before tavl_find3() saying &gt=3B &gt=3B /* &gt= =3B &gt=3B * tavl_find2 - returns Avlnode instead of data pointer. &gt= =3B &gt=3B * tavl_find3 - as above=2C but returns Avlnode even if no match = is found. &gt=3B &gt=3B * also set *ret =3D last comparison result=2C or= -1 if root =3D=3D NULL. &gt=3B &gt=3B */ &gt=3B &gt=3B &gt=3B &gt= =3B but the "or -1 if root =3D=3D NULL" is not done. &gt=3B &gt=3B &g= t=3B &gt=3B Secondly=2C if no exact match is found=2C prev is returned whic= h may point to a node which is less than the search &gt=3B &gt=3B node= =2C depending on what the tree looks like=2C but we really want a pointer t= o the last node which was greater than &gt=3B &gt=3B the search node to = be returned. &gt=3B &gt=3B &gt=3B &gt=3B Once these fixes are done=2C= the correct node is returned by tavl_find3 to the call in send_list() in s= ssvlv.c (line 523). &gt=3B &gt=3B &gt=3B &gt=3B There is another bug = in send_list() in sssvlv.c=2C at lines 535-544: &gt=3B &gt=3B &gt=3B = &gt=3B if ( i &gt=3B 0 ) { &gt=3B &gt=3B tmp_node =3D tavl_end(so-&gt=3B= so_tree=2C TAVL_DIR_RIGHT)=3B &gt=3B &gt=3B dir =3D TAVL_DIR_LEFT=3B = &gt=3B &gt=3B } else { &gt=3B &gt=3B tmp_node =3D tavl_end(so-&gt=3Bso_t= ree=2C TAVL_DIR_LEFT)=3B &gt=3B &gt=3B dir =3D TAVL_DIR_RIGHT=3B &gt= =3B &gt=3B } &gt=3B &gt=3B for (i=3D0=3B tmp_node !=3D cur_node=3B &g= t=3B &gt=3B tmp_node =3D tavl_next( tmp_node=2C dir )=2C i++)=3B &gt=3B = &gt=3B so-&gt=3Bso_vlv_target =3D i=3B &gt=3B &gt=3B This code is ok if = the cur_node is in the left hand side of the tree=2C but if it is in the rh= s of the tree so_vlv_target is set &gt=3B &gt=3B to an offset from the e= nd of the list=2C rather than the beginning. &gt=3B &gt=3B &gt=3B = &gt=3B One more issue: the most recent draft spec for vlv (http://tools.iet= f.org/html/draft-ietf-ldapext-ldapv3-vlv-09) states that the offset field i= n the vlv request has range 1..maxInt whereas the targetPosition in the vlv= response has range 0..maxInt. &gt=3B &gt=3B However=2C my interpreta= tion of the spec is that offset and targetPosition represent the same thing= =2C i.e. the position of the target entry in the list=2C with the first ent= ry having offset/targetPosition =3D 1. &gt=3B &gt=3B If that interpre= tation is correct=2C the assignment of so_vlv_target in the code above is o= ff by one=2C since i will be zero if cur_node is at the beginning of the li= st. &gt=3B I've uploaded a patch to ftp.openldap.org=2C incoming/= Chris-Card-110708.ITS-6985-fix.patch </div><div>Chris </div> = </div></body> </html>= --_3d71bf45-bf8f-4026-9c30-d39291bf9f56_--

1 0

(ITS#6996) Bad cn=config quotes in Admin Guide
by h.b.furuseth＠usit.uio.no 15 Jul '11

15 Jul '11

Full_Name: Hallvard B Furuseth Version: master, 2.4.26 OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard http://www.openldap.org/doc/admin24/slapdconf2.html contains a number of examples with quoted DNs in cn=config attributes: olcSuffix, olcRootDN. This is wrong, likely a cut&paste from slapd.conf.

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs July 2011