openldap-bugs

openldap-bugs@openldap.org

1 participants
21003 discussions

Re: (ITS#6770) Proxy authorization fails with SASL-GSSAPI
by c.waeschenfelder＠websale.de 20 Jul '11

20 Jul '11

> Something in this area should have been fixed in master code; some fixes > may have been released in 2.4.26. Can you indicate what version you're > using? In case you're using the latest, can you test with master code? > > p. The problem seems already solved in 2.4.26. The authorization seems to work reliable now, I couldn't recognize any authorization errors after upgrading to 2.4.26.

1 0

Re: (ITS#6770) Proxy authorization fails with SASL-GSSAPI
by masarati＠aero.polimi.it 20 Jul '11

20 Jul '11

Please keep replies in cc with the ITS. On 07/20/2011 10:28 AM, Christian Wäschenfelder wrote: > >> Something in this area should have been fixed in master code; some fixes >> may have been released in 2.4.26. Can you indicate what version you're >> using? In case you're using the latest, can you test with master code? >> >> p. >> > > At the moment I'm using 2.4.23-7 on debian squeeze. > I'll try it with 2.4.26 and master code. > > Ahhm... were can I get the master code, just download via git? yes. p.

1 0

Re: (ITS#6770) Proxy authorization fails with SASL-GSSAPI
by masarati＠aero.polimi.it 19 Jul '11

19 Jul '11

> Same problem here: > > If I use the cn=config style, proxy authorization works directly after > configuring it. > If I reboot the slave server the authorization fails to work and the > bindmethod switches from SASL/GSSAPI to SIMPLE. > > If I delete the configuration directory /etc/ldap/slapd.d and use a > simple /etc/ldap/slapd.conf and make the same configuration the old way > everything keeps working after reboots. > > So I think there is a Problem while loading the cn=config configuration. Something in this area should have been fixed in master code; some fixes may have been released in 2.4.26. Can you indicate what version you're using? In case you're using the latest, can you test with master code? p.

1 0

(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

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