- openldap-bugs - openldap.org

(ITS#6999) retry: counter not reaching zero, continuing on
by ml+openldap＠esmtp.org 25 Jul '11

25 Jul '11

Full_Name: Claus Assmann Version: 2.4.23 OS: Red Hat Enterprise Linux Server release 5.5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (63.211.143.38) While trying to determine how syncrepl behaves in various error conditions, I encountered an unexpected behaviour in which the retry specification doesn't seem to work. A MASTER is set up to use push replication to a REPLICA as follows: database ldap hidden on suffix "" rootdn "cn=slapd-ldap" uri ldap://REPLICA/ lastmod on restrict all sync_use_subentry true acl-bind bindmethod=simple binddn="cn=Monitor" credentials=password syncrepl rid=001 provider=ldapi://%2Fvar%2Frun%2Fldapi binddn="cn=Manager" bindmethod=simple credentials=passwd searchbase="" type=refreshAndPersist retry="5 5 60 +" When I stop the REPLICA and add an entry on the MASTER, then the MASTER is retrying every 5s and claims that 4 (sometimes 3) retries are left: Jul 22 13:12:52 MASTER slapd[23778]: do_syncrepl: rid=001 rc 52 retrying (4 retries left) Jul 22 13:12:57 MASTER slapd[23778]: do_syncrepl: rid=001 rc 52 retrying (3 retries left) Jul 22 13:13:02 MASTER slapd[23778]: do_syncrepl: rid=001 rc 52 retrying (4 retries left) Jul 22 13:13:07 MASTER slapd[23778]: do_syncrepl: rid=001 rc 52 retrying (3 retries left) Jul 22 13:13:12 MASTER slapd[23778]: do_syncrepl: rid=001 rc 52 retrying (4 retries left) Jul 22 13:13:17 MASTER slapd[23778]: do_syncrepl: rid=001 rc 52 retrying (4 retries left) Jul 22 13:13:22 MASTER slapd[23778]: do_syncrepl: rid=001 rc 52 retrying (4 retries left) Jul 22 13:13:28 MASTER slapd[23778]: do_syncrepl: rid=001 rc 52 retrying (4 retries left) Jul 22 13:13:33 MASTER slapd[23778]: do_syncrepl: rid=001 rc 52 retrying (4 retries left) Jul 22 13:13:38 MASTER slapd[23778]: do_syncrepl: rid=001 rc 52 retrying (4 retries left) Jul 22 13:13:43 MASTER slapd[23778]: do_syncrepl: rid=001 rc 52 retrying (4 retries left) Jul 22 13:13:48 MASTER slapd[23778]: do_syncrepl: rid=001 rc 52 retrying (4 retries left) Jul 22 13:13:53 MASTER slapd[23778]: do_syncrepl: rid=001 rc 52 retrying (4 retries left) Jul 22 13:13:58 MASTER slapd[23778]: do_syncrepl: rid=001 rc 52 retrying (4 retries left) When I start REPLICA again, syncrepl succeeds. Do I have to set some other option such that the retry specification is actually used? That is, try every 5s for 5 times, then try every 60s. Or is the retry logic dependent on the error syncrepl encounters? The full log for one failed retry is: conn=1004 op=0 BIND dn="cn=manager" method=128 conn=1004 op=0 BIND dn="cn=manager" mech=SIMPLE ssf=0 conn=1004 op=0 RESULT tag=97 err=0 text= conn=1004 op=1 SRCH base="" scope=2 deref=0 filter="(objectClass=*)" conn=1004 op=1 SRCH attr=* + srs csn 20110722201233.471069Z#000000#001#000000 log csn 20110722201233.471069Z#000000#001#000000 cmp 0, too old log csn 20110722201252.820971Z#000000#001#000000 Entry uid=user68,ou=People,dc=example,dc=com CSN 20110722201233.471069Z#000000#001#000000 older or equal to ctx 20110722201233.471069Z#000000#001#000000 syncprov_search_response: cookie=rid=001,sid=001,csn=20110722201252.820971Z#000000#001#000000 syncrepl_entry: rid=001 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) syncrepl_entry: rid=001 inserted UUID 95b838a2-4b55-4bcc-8b00-be329b138db0 conn=1004 fd=15 ACCEPT from PATH=/var/run/ldapi (PATH=/var/run/ldapi) syncrepl_entry: rid=001 be_search (52) syncrepl_entry: rid=001 uid=user69,ou=People,dc=example,dc=com null_callback : error code 0x34 syncrepl_entry: rid=001 be_add uid=user69,ou=People,dc=example,dc=com (52) syncrepl_entry: rid=001 be_add uid=user69,ou=People,dc=example,dc=com failed (52) do_syncrepl: rid=001 rc 52 retrying (4 retries left) conn=1004 op=2 UNBIND conn=1004 fd=15 closed connection_read(15): no connection! connection_read(15): no connection!

1 0

(ITS#6998) MozNSS: when server certificate is not required, ignore expired issuer errors
by jvcelak＠redhat.com 20 Jul '11

20 Jul '11

Full_Name: Jan Vcelak Version: 2.4.26 OS: Linux URL: ftp://ftp.openldap.org/incoming/jvcelak-nss-ignore-issuer-expiration-110720… Submission from: (NULL) (209.132.186.34) Hello. When the server certificate validity is not required in a TLS session (e.g. TLS_REQCERT is set to 'never'), expired certificate of the issuer of the server certificate causes the connection to be terminated. Uploaded patch fixes this by adding SEC_ERROR_EXPIRED_ISSUER_CERTIFICATE error to the list of ignored errors, when the certificate is not being checked. The patch is created against OPENLDAP_REL_ENG_2_4 branch. Jan

1 0

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

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

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

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

1 0

(ITS#6995) Request for Contribution of Identity Access Management Software to OpenLDAP Project
by shawn.mckinney＠jtstools.com 14 Jul '11

14 Jul '11

Full_Name: Shawn McKinney Version: All OS: All URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (99.34.198.251) Hello, We have created a new Identity and Access Management SDK, called Fortress, that uses Java and OpenLDAP to provide authentication, RBAC, ARBAC, password policies, auditing and more. It has taken us 2.5 years of steady work to get it ready for this 1.0 release. This SDK has approximately 50K lines of Java code of which approximately 25K are dedicated to testing using JUnit automated tests to ensure it works correctly. There are in excess of 100 public APIs available for use. There is also a Java EE container plug-in that provides authentication and authorization services to Websphere, Tomcat and JBoss app servers in a declarative fashion. This product has not been published and we would like to release it as one of the products under OpenLDAP family of products. The product will be released under New BSD open source license (license information is contained in the source archives on ftp server). I have uploaded seven packages to our FTP server that contain the source, documentation and other items for you to look at. host: jtstools.com user: jtsguest1 pw: OpenLd@p1 The packages are as follows: Fortress Core SDK 1. source - fortressSrc-1.0.0-rc1.zip - 352K bytes 2. source - fortressTestSrc-1.0.0-rc1.zip - 159K bytes 3. tutorial/doc - fortressSamples-1.0.0-rc1.zip - 766K bytes 4. javadoc - fortressDoc-1.0.0-rc1.zip - 1.4M bytes 5. ldap (folder) - Fortress schema and OpenLDAP slapd.conf Fortress Realm (Java EE Container plug-ins) 6. source - fortressRealmSrc-1.0.0-rc1.zip - 45K bytes 7. javadoc - fortressRealmDoc-1.0.0-rc1.zip - 76K bytes Package 4 contains complete javadoc for the APIs. In package 4, this link, ./fortressDoc-1.0.0-rc1/index.html, contains the overall summary of the SDK. this link, ./oamCore/trunk/dist/docs/api/index.html, contains package descriptions along with detailed documentation describing the contents of the SDK. What we are requesting from the OpenLDAP foundation: 1. Source code repository to host the SDK and Realm packages. 2. Bug tracking. 3. Developer and User forums. 4. Wiki (this is a nice to have) Our goal is to run the open source project with your organization and cultivate a healthy developer and user community. We have high hopes for this product (and OpenLDAP) and consider the 2 products together as an open source alternative for IAM products that will compete with the commercial vendor offerings. Once 1.0 is released, we will begin working on 2.0 which will include UI's to control Fortress and OpenLDAP along with a policy server to wrap the Fortress Java APIs with HTTP/REST Web APIs to make it available to all platforms. Thanks in advance for your consideration. Shawn McKinney JoshuaTree Software shawn.mckinney(a)jtstools.com

1 0

(ITS#6994) Syncrepl with MozNSS inherits TLS context form main configuration breaking some syncrepl setups
by thibault.lemeur＠supelec.fr 11 Jul '11

11 Jul '11

Full_Name: Thibault Le Meur Version: 2.4.23-15 OS: RHEL6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (160.228.28.55) Previously on my FC13 installation (openldap-servers-2.4.21-11) the main slapd process used an X509 "server" while my syncrepl processes were using the /etc/openldap/ldap.conf client configuration file in order to connect to my LDAPs Syncrepl providers. In my new RHEL6 setup (openldap-servers-2.4.23-15.el6.x86_64) is linked to MozNSS and Syncrepl can't connect to my LDAPs providers anymore because it complains about the TLS context not beeing intitialized correctly (the server's certificate isn't accepted as a client certificate). Here is the lightly obfuscated log: ---------------------------------------------------------- ldap_connect_to_host: Trying 10.10.10.10:636 ldap_pvt_connect: fd: 21 tm: -1 async: 0 TLS: loaded CA certificate file /etc/ssl/cacerts/cacert.pem. TLS: certificate [CN=myldap.mydom.fr,OU=myou,O=myorg,L=myloc,ST=myst,C=FR] is not valid - error -8101:Unknown code ___f 91. TLS: error: unable to set up client certificate authentication for certificate named PEM Token #0:myldap.mydom.fr-cert.pem - 0 TLS: error: unable to set up client certificate authentication using PEM Token #0:myldap.mydom.fr-cert.pem - 0 TLS: error: could not initialize moznss security context - error -8101:Unknown code ___f 91 TLS: can't create ssl handle. slap_client_connect: URI=ldaps://otherldap.mydom.fr DN="cn=myreplicationAccount,dc=mydom,dc=fr" ldap_sasl_bind_s failed (-1) do_syncrepl: rid=125 rc -1 retrying (9 retries left) ---------------------------------------------------------- Here is my syncrepl setup: --------------------------------------------------------- syncrepl rid=125 provider=ldaps://otherldap.mydom.fr type=refreshOnly interval=00:00:03:00 retry="60 10 300 +" searchbase="dc=subranch,dc=mydom,dc=fr" filter="(objectClass=*)" scope=sub schemachecking=off bindmethod=simple binddn="cn=myreplicationAccount,dc=mydom,dc=fr" credentials="MyVerySecretPassword" --------------------------------------------------------- My setup related to TLS: --------------------------------------------------------- TLSCipherSuite HIGH TLSCertificateFile /etc/ssl/certs/myldap.mydom.fr-cert.pem TLSCertificateKeyFile /etc/ssl/keys/myldap.mydom.fr-key.pem TLSCACertificateFile /etc/ssl/cacerts/cacert.pem --------------------------------------------------------- And my /etc/openldap/ldap.conf: --------------------------------------------------------- TLS_CACERT /etc/ssl/cacerts/cacert.pem --------------------------------------------------------- Here is the obfuscated certificate: --------------------------------------------------------- Certificate: Data: Version: 3 (0x2) Serial Number: 221 (0xdd) Signature Algorithm: sha1WithRSAEncryption Issuer: C=FR, ST=myst, L=myloc, O=myorg, OU=myou, CN=myCA/emailAddress=myemail(a)mydom.fr Validity Not Before: Oct 2 16:42:15 2007 GMT Not After : Dec 14 16:42:15 2012 GMT Subject: C=FR, ST=myst, L=myloc, O=myorg, OU=myou, CN=myldap.mydom.fr Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) Modulus: ... Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Basic Constraints: CA:FALSE Netscape Cert Type: SSL Server Netscape Comment: TinyCA Generated Certificate X509v3 Subject Key Identifier: ... X509v3 Authority Key Identifier: keyid:... DirName:/C=FR/ST=myst/L=myloc/O=myorg/OU=myou/CN=myCA/emailAddress=thibault.lemeur@supelec.fr serial:00 X509v3 Issuer Alternative Name: <EMPTY> Netscape SSL Server Name: myldap.mydom.fr X509v3 Subject Alternative Name: DNS:ldap, DNS:ldapalias1, DNS:ldapalias2, DNS:ldapalias1.mydom.fr, DNS:ldapalias2.mydom.fr, DNS:ldap.mydom.fr, DNS:myldap, DNS:myldap.mydom.fr X509v3 Extended Key Usage: critical TLS Web Server Authentication, Code Signing Signature Algorithm: sha1WithRSAEncryption ... ---------------------------------------------------------

1 0

(ITS#6993) Backend Connection problem
by yann.carre＠alcatel-lucent.com 11 Jul '11

11 Jul '11

Full_Name: Yann Carre Version: 2.4.26 OS: red hat 5 (64 bits) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (64.208.49.20) I work on a specific Backend I have provided in my back end a function to the bi_connection_init pointer. This function adds a context needed in the operation backend function (search, ...) When several connections start up, my LDAP server crashes. The crash arrives because the context is not created before the call to do_searh. The connection is provided to the application Backend before my Back end connection_init. I have checked it with the debugger and see that the thread with initialize the connection is suspend before the backend connection_init. In another thread, the search function is executed without any context attached to the connection. This problem seems to be bring because the connection mutex is freed before the calling of the Back end connection_init in the function connection_init (connection.c). I have moved this mutex after the backend connection_init and it seems to work. Would you confirm this analysis and take the correction in account? Thanks Regards Yann

1 0

Syncrepl using can't start ssl session because of refused certificate
by Thibault Le Meur 10 Jul '11

10 Jul '11

Hello, I'm trying to upgrade an openLdap server from FC9 (openldap-servers-2.4.10-2.fc9.i386) to Redhat Enterprise 6 (openldap-servers-2.4.23-15.el6.x86_64). In this new setup, my local database works but the Syncrepl replication process fails to establish the "ldaps://" session to my syncrepl-providers because the TLS layer fails. Indeed, the TLS layer complains that my _server's certificate_ isn't a valid _client certificate_ (with error 8101 - SEC_ERROR_INADEQUATE_CERT_TYPE): but I don't want client-side authentication! In the past syncrepl didn't try to use the server certificate as a client certificate, and I haven't seen any reference to this in the documentation. I first thought it could have been related to ITS#6791 but I don't think so anymore because it only affects Syncrepl. Don' hesitate to redirect me to the openldap-users list if I've missed something simple. Thanks in advance, Thibault Here is an excerpt of slapd in debug-mode: ---------------------------------------------------------- ldap_connect_to_host: Trying 10.10.10.10:636 ldap_pvt_connect: fd: 21 tm: -1 async: 0 TLS: loaded CA certificate file /etc/ssl/cacerts/cacert.pem. TLS: certificate [CN=myldap.mydom.fr,OU=myou,O=myorg,L=myloc,ST=myst,C=FR] is not valid - error -8101:Unknown code ___f 91. TLS: error: unable to set up client certificate authentication for certificate named PEM Token #0:myldap.mydom.fr-cert.pem - 0 TLS: error: unable to set up client certificate authentication using PEM Token #0:myldap.mydom.fr-cert.pem - 0 TLS: error: could not initialize moznss security context - error -8101:Unknown code ___f 91 TLS: can't create ssl handle. slap_client_connect: URI=ldaps://otherldap.mydom.fr DN="cn=myreplicationAccount,dc=mydom,dc=fr" ldap_sasl_bind_s failed (-1) do_syncrepl: rid=125 rc -1 retrying (9 retries left) ---------------------------------------------------------- Here is my syncrepl setup: --------------------------------------------------------- syncrepl rid=125 provider=ldaps://otherldap.mydom.fr type=refreshOnly interval=00:00:03:00 retry="60 10 300 +" searchbase="dc=subranch,dc=mydom,dc=fr" filter="(objectClass=*)" scope=sub schemachecking=off bindmethod=simple binddn="cn=myreplicationAccount,dc=mydom,dc=fr" credentials="MyVerySecretPassword" --------------------------------------------------------- And eventually my /etc/openldap/ldap.conf: --------------------------------------------------------- TLS_CACERT /etc/ssl/cacerts/cacert.pem ---------------------------------------------------------

2 1

connection init crash
by Yann Carre 10 Jul '11

10 Jul '11

Hello I have encountered a crash with OPENLDAP 2.4.22 I have provided in my back end a function to the bi_connection_init pointer. This function sets some parameter needed in the operation backend function (search, ...) My server crashes because my backend connection init function is not called before the operation backend function. It seems that the connection is provided to the application before the end of all backend connection init May be in the function connection_init (connection.c), the connection mutex should be unlock when all the backend connection init should be done? Thanks Regards Yann

2 1

Re: (ITS#6992) ldapsync.c empty initializer
by masarati＠aero.polimi.it 08 Jul '11

08 Jul '11

On 07/08/2011 07:45 AM, tim(a)multitalents.net wrote: > Full_Name: Tim Rice > Version: 2.4.26 > OS: Solaris 10& UnixWare 7.1.4 > URL: > Submission from: (NULL) (173.164.249.129) > > > The solaris native compilers complain about empty initializer in > servers/slapd/ldapsync.c A fix is in git master, please test and report. p.

1 0

(ITS#6992) ldapsync.c empty initializer
by tim＠multitalents.net 07 Jul '11

07 Jul '11

Full_Name: Tim Rice Version: 2.4.26 OS: Solaris 10 & UnixWare 7.1.4 URL: Submission from: (NULL) (173.164.249.129) The solaris native compilers complain about empty initializer in servers/slapd/ldapsync.c ........... cc -fast -xtarget=ultra -xcode=pic32 -g -I../../include -I/opt/src/networking/openldap-2.4.26/servers/slapd -I/opt/src/networking/openldap-2.4.26/servers/slapd/slapi -I. -I/opt/src/networking/openldap-2.4.26/include -I/opt/include -I/usr/sfw/include -c -o ldapsync.o /opt/src/networking/openldap-2.4.26/servers/slapd/ldapsync.c "/opt/src/networking/openldap-2.4.26/servers/slapd/ldapsync.c", line 172: warning: syntax error: empty initializer "/opt/src/networking/openldap-2.4.26/servers/slapd/ldapsync.c", line 174: warning: syntax error: empty initializer "/opt/src/networking/openldap-2.4.26/servers/slapd/ldapsync.c", line 175: warning: syntax error: empty initializer "/opt/src/networking/openldap-2.4.26/servers/slapd/ldapsync.c", line 180: warning: syntax error: empty initializer ........... It does compile on Solaris, but on UnixWare it is an error so fails to compile. ........... cc -g -Kpthread -I../../include -I. -I./slapi -I. -I../../include -c -o ldapsync.o ldapsync.c UX:acomp: ERROR: "ldapsync.c", line 172: Syntax error before or at: } UX:acomp: ERROR: "ldapsync.c", line 178: syntax error, probably missing ",", ";" or "=" UX:acomp: WARNING: "ldapsync.c", line 178: parameter mismatch: 6 declared, 3 defined UX:acomp: WARNING: "ldapsync.c", line 178: syntax error: empty declaration UX:acomp: ERROR: "ldapsync.c", line 179: cannot recover from previous errors gmake[2]: *** [ldapsync.o] Error 1 ...........

1 0

Re: (ITS#6987) cn=config renumbers indexes on startup without modrdn-ing them
by ondrej.kuznik＠acision.com 07 Jul '11

07 Jul '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/07/2011 11:16 AM, masarati(a)aero.polimi.it wrote: >> When storing cn=config entries whose rdns use different attributes, >> they may be received in a different order during startup. This will >> mess with their "{}" numbering and since a change like that is not >> anticipated in the code, it is never pushed to the underlying >> database either. >> >> This leads to a state when the cn=config database and underlying >> on-disk representation are out of sync, making modification (and >> maybe deletion) of the affected entries impossible. >> >> If needed, I can create a minimal overlay showing these symptoms. > > Please, do. I find this report quite unclear, as I could not understand > what the actual issue is. ftp://ftp.openldap.org/incoming/ondrej-kuznik-20110707.c has an example of such overlay. To try it, initialize the overlay and add these entries: dn: olcTestAttrOne=zero,$OVERLAY_DN objectclass: olcTestOne dn: olcTestAttrTwo=one,$OVERLAY_DN objectclass: olcTestTwo dn: olcTestAttrOne=two,$OVERLAY_DN objectclass: olcTestOne dn: olcTestAttrTwo=three,$OVERLAY_DN objectclass: olcTestTwo After a restart compare the output of slapcat -n0 with the output of ldapsearch -b cn=config, you should see at least one different entry. You might also try to modify the entries before and after the restart. For those that do not match you get "no such object" as the dn is no longer in the ldif database. - -- Ondrej Kuznik -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4Vs7IACgkQ9GWxeeH+cXs3rwCeP4DpQv+YNzWSt3sEgTZRVsYK 1ZYAoKiZeHPPWQ/kGirlkLMXitToxYqd =nAEI -----END PGP SIGNATURE----- This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.

1 0

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

07 Jul '11

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

1 0

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

07 Jul '11

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

1 0

Re: (ITS#6987) cn=config renumbers indexes on startup without modrdn-ing them
by masarati＠aero.polimi.it 07 Jul '11

07 Jul '11

> Full_Name: Ondrej Kuznik > Version: HEAD > OS: Linux > URL: > Submission from: (NULL) (62.168.56.1) > > > When storing cn=config entries whose rdns use different attributes, they > may be > received in a different order during startup. This will mess with their > "{}" > numbering and since a change like that is not anticipated in the code, it > is > never pushed to the underlying database either. > > This leads to a state when the cn=config database and underlying on-disk > representation are out of sync, making modification (and maybe deletion) > of the > affected entries impossible. > > If needed, I can create a minimal overlay showing these symptoms. Please, do. I find this report quite unclear, as I could not understand what the actual issue is. p.

1 0

(ITS#6987) cn=config renumbers indexes on startup without modrdn-ing them
by ondrej.kuznik＠acision.com 07 Jul '11

07 Jul '11

Full_Name: Ondrej Kuznik Version: HEAD OS: Linux URL: Submission from: (NULL) (62.168.56.1) When storing cn=config entries whose rdns use different attributes, they may be received in a different order during startup. This will mess with their "{}" numbering and since a change like that is not anticipated in the code, it is never pushed to the underlying database either. This leads to a state when the cn=config database and underlying on-disk representation are out of sync, making modification (and maybe deletion) of the affected entries impossible. If needed, I can create a minimal overlay showing these symptoms. Not sure what action is appropriate, probably letting back-ldif honor the original ordering fully, but this can break other assumptions already in the configuration code that relied on the "attribute name first, then numbers" ordering. Another thing that comes to my mind is to make the ordering sequences per attribute whatever the value of ce_type. Like this: olcAttr={0}a, olcSomething={0}something, cn=config olcAttr={1}c, olcSomething={0}something, cn=config olcAttr={2}b, olcSomething={0}something, cn=config olcOtherAttr={0}ccc, olcSomething={0}something, cn=config olcOtherAttr={1}csad, olcSomething={0}something, cn=config olcOtherAttr={2}safc, olcSomething={0}something, cn=config olcOtherAttr={3}brt, olcSomething={0}something, cn=config Again, this has other drawbacks (first restart after this is applied changes the cn=config database probably messing with replication?)

1 0

Re: (ITS#6986) conversion to run-time configuration (RTC) for slapo-constraint
by florian.dufner＠uni-ulm.de 07 Jul '11

07 Jul '11

Am 07.07.2011 08:21, schrieb masarati(a)aero.polimi.it: > There are clearly two bugs: "count" misses the number (same for "size") > and the prefix "restrict=" is repeated. Fixed in master, please test and > report. Tested. Problem is gone with the provided patch. Thank you. FloD.

1 0

Re: (ITS#6986) conversion to run-time configuration (RTC) for slapo-constraint
by masarati＠aero.polimi.it 06 Jul '11

06 Jul '11

There are clearly two bugs: "count" misses the number (same for "size") and the prefix "restrict=" is repeated. Fixed in master, please test and report. p. > --On Tuesday, July 05, 2011 9:22 PM +0000 florian.dufner(a)uni-ulm.de wrote: > >> Full_Name: Florian Dufner >> Version: 2.4.26 >> OS: SunOS sun 5.10 i86pc >> URL: >> Submission from: (NULL) (91.16.117.246) >> >> >> Conversion to run-time configuration (RTC) does not work with every >> configuration option of slapo-constraint. >> >> Problem #1: (count constraints) >> constraint_attribute mail count 1 >> is converted to >> olcConstraintAttribute:: bWFpbCBjb3VudCA= > > This is base-64 encoded, not garbage. I suggest you base-64 decode it to > see the actual value. > >> The attribute is garbled after conversion. slapd will not run until this >> is fixed. >> >> Problem #2: (restrict parameter) >> constraint_attribute mail regex ^[[:alnum:].-]+@host$ >> restrict="ldap:///ou=people,dc=host??sub?(objectClass=posixAccount)" >> is converted to >> olcConstraintAttribute: mail regex ^[[:alnum:].-]+@host$ restr >> ict="restrict=ldap:///ou=people,dc=host??sub?(obj >> ectClass=posixAccount)" >> >> The complete restrict parameter from the old configuration format >> (including "restrict=") is appended after a "restrict=". >> slapd will not run until this is fixed. >> > > This sounds valid. > > --Quanah > > -- > > Quanah Gibson-Mount > Sr. Member of Technical Staff > Zimbra, Inc > A Division of VMware, Inc. > -------------------- > Zimbra :: the leader in open source messaging and collaboration > > >

1 0

Re: (ITS#6986) conversion to run-time configuration (RTC) for slapo-constraint
by florian.dufner＠uni-ulm.de 06 Jul '11

06 Jul '11

Am 07.07.2011 04:12, schrieb Quanah Gibson-Mount: >> Problem #1: (count constraints) >> constraint_attribute mail count 1 >> is converted to >> olcConstraintAttribute:: bWFpbCBjb3VudCA= > > This is base-64 encoded, not garbage. I suggest you base-64 decode it > to see the actual value. Okay, base-64 decoded it is "mail count". But as I wrote: >> The attribute is garbled after conversion. slapd will not run until this >> is fixed. So the problem is that the number after count is not included in conversion. After adding " <number>" slapd will start. Is there a specific mechanism for the decision of what attributes get base64-encoded in conversion? In case of the count type constraint I can't see why it's needed. FloD.

1 0

Re: (ITS#6986) conversion to run-time configuration (RTC) for slapo-constraint
by quanah＠zimbra.com 06 Jul '11

06 Jul '11

--On Tuesday, July 05, 2011 9:22 PM +0000 florian.dufner(a)uni-ulm.de wrote: > Full_Name: Florian Dufner > Version: 2.4.26 > OS: SunOS sun 5.10 i86pc > URL: > Submission from: (NULL) (91.16.117.246) > > > Conversion to run-time configuration (RTC) does not work with every > configuration option of slapo-constraint. > > Problem #1: (count constraints) > constraint_attribute mail count 1 > is converted to > olcConstraintAttribute:: bWFpbCBjb3VudCA= This is base-64 encoded, not garbage. I suggest you base-64 decode it to see the actual value. > The attribute is garbled after conversion. slapd will not run until this > is fixed. > > Problem #2: (restrict parameter) > constraint_attribute mail regex ^[[:alnum:].-]+@host$ > restrict="ldap:///ou=people,dc=host??sub?(objectClass=posixAccount)" > is converted to > olcConstraintAttribute: mail regex ^[[:alnum:].-]+@host$ restr > ict="restrict=ldap:///ou=people,dc=host??sub?(obj > ectClass=posixAccount)" > > The complete restrict parameter from the old configuration format > (including "restrict=") is appended after a "restrict=". > slapd will not run until this is fixed. > This sounds valid. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6986) conversion to run-time configuration (RTC) for slapo-constraint
by florian.dufner＠uni-ulm.de 05 Jul '11

05 Jul '11

Full_Name: Florian Dufner Version: 2.4.26 OS: SunOS sun 5.10 i86pc URL: Submission from: (NULL) (91.16.117.246) Conversion to run-time configuration (RTC) does not work with every configuration option of slapo-constraint. Problem #1: (count constraints) constraint_attribute mail count 1 is converted to olcConstraintAttribute:: bWFpbCBjb3VudCA= The attribute is garbled after conversion. slapd will not run until this is fixed. Problem #2: (restrict parameter) constraint_attribute mail regex ^[[:alnum:].-]+@host$ restrict="ldap:///ou=people,dc=host??sub?(objectClass=posixAccount)" is converted to olcConstraintAttribute: mail regex ^[[:alnum:].-]+@host$ restr ict="restrict=ldap:///ou=people,dc=host??sub?(obj ectClass=posixAccount)" The complete restrict parameter from the old configuration format (including "restrict=") is appended after a "restrict=". slapd will not run until this is fixed.

1 0

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

05 Jul '11

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

1 0

Re: (ITS#6985) sssvlv / greaterThanOrEqual problem
by masarati＠aero.polimi.it 05 Jul '11

05 Jul '11

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

1 0

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

05 Jul '11

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.

1 0

Re: (ITS#6984) Enable draft-wahl-ldap-session in RE24
by masarati＠aero.polimi.it 04 Jul '11

04 Jul '11

> Full_Name: Michael Ströder > Version: 2.4.x > OS: > URL: > Submission from: (NULL) (84.128.228.27) > > > It seems there is support for draft-wahl-ldap-session in OpenLDAP's source > since > 2007 but it seems not to be enabled in a default build. It's hidden behind > ifdef-statements and one has to use -DLDAP_DEVEL when compiling which is > not > supposed to work with RE24. > > I've tested it with HEAD and I'd be glad this could be enabled for > standard > builds in 2.4 series. As far as I understand, support is complete and conforms to draft as of the time it was implemented. Since the draft expired, it has never been released. Moreover, I sent the author some comments about how the draft could be improved, IMHO, but received no answer (I don't recall whether the discussion was in ldapext or personal, though). If it can be useful, I surely favour its release, provided this complies with the project's policy towards support for expired drafts. p.

1 0

(ITS#6984) Enable draft-wahl-ldap-session in RE24
by michael＠stroeder.com 04 Jul '11

04 Jul '11

Full_Name: Michael Ströder Version: 2.4.x OS: URL: Submission from: (NULL) (84.128.228.27) It seems there is support for draft-wahl-ldap-session in OpenLDAP's source since 2007 but it seems not to be enabled in a default build. It's hidden behind ifdef-statements and one has to use -DLDAP_DEVEL when compiling which is not supposed to work with RE24. I've tested it with HEAD and I'd be glad this could be enabled for standard builds in 2.4 series. Ciao, Michael.

1 0

(ITS#6983) modrdn operations on hdb databases create duplicate return results
by quanah＠zimbra.com 02 Jul '11

02 Jul '11

Full_Name: Quanah Gibson-Mount Version: 2.4.25 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.45.108) When a modrdn operation is done on a subtree (I.e., subtree rename), the result is that back-hdb will return certain entries in that subtree multiple times. Stopping and restarting slapd fixes the behavior. Example: ldapsearch -x -v -H 'ldap://HOST ' -w PASSWORD -D 'uid=zimbra,cn=admins,cn=zimbra' -b "dc=NEWDOMAIN,dc=COM" ldap_initialize( ldap://HOST:389/??base ) filter: (objectclass=*) requesting: All userApplication attributes # extended LDIF # # LDAPv3 # base <dc=NEWDOMAIN,dc=COM> with scope subtree # filter: (objectclass=*) # requesting: ALL # # d-fashion.be dn: dc=NEWDOMAIN,dc=COM o: NEWDOMAIN.com domain zimbraDomainName: NEWDOMAIN.COM zimbraDomainStatus: active zimbraPublicServiceHostname: mail.domain.com zimbraId: affb06b8-79bc-430a-adf7-411cc45e8f00 zimbraMailStatus: enabled objectClass: dcObject objectClass: organization objectClass: zimbraDomain zimbraDomainType: local dc: NEWDOMAIN zimbraPreAuthKey: PRIVATE # people, NEWDOMAIN.COM dn: ou=people,dc=NEWDOMAIN,dc=COM ou: people objectClass: organizationalRole cn: people # people, NEWDOMAIN.COM dn: ou=people,dc=NEWDOMAIN,dc=COM ou: people objectClass: organizationalRole cn: people

1 0

Re: ITS#6873
by masarati＠aero.polimi.it 01 Jul '11

01 Jul '11

> masarati(a)aero.polimi.it wrote: >> Fixed in master, please test. > > Sorry, last message went to wrong ITS. > > But also seems to work now...thanks... :-) > > $ ldapmodify -x -H ldap://localhost:2071 -D > "uid=diradm,ou=schulung,dc=stroeder,dc=local" -e relax -w testsecret -f > authtime_mod.ldif > modifying entry "cn=test1,ou=schulung,dc=stroeder,dc=local" > > -------------------------- authtime_mod.ldif -------------------------- > dn: cn=test1,ou=schulung,dc=stroeder,dc=local > changetype: modify > replace: authTimestamp > authTimestamp: 20110701165029Z Good, I only tested this one. Those were easy fixes, sorry I overlooked them for such a long time. p.

1 0

Re: (ITS#6830) slapo-ppolicy.5 has incorrect schema fragments
by michael＠stroeder.com 01 Jul '11

01 Jul '11

hyc(a)symas.com wrote: > Andrew Findlay wrote: >> On Thu, Jun 09, 2011 at 01:45:17AM -0700, Howard Chu wrote: >> >>> I note that in ppolicy.c we have: >>> >>> { "( 1.3.6.1.4.1.42.2.27.8.1.17 " >>> "NAME ( 'pwdAccountLockedTime' ) " >>> "DESC 'The time an user account was locked' " >>> "EQUALITY generalizedTimeMatch " >>> "ORDERING generalizedTimeOrderingMatch " >>> "SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 " >>> "SINGLE-VALUE " >>> #if 0 >>> /* Not until Relax control is released */ >>> "NO-USER-MODIFICATION " >>> #endif >>> "USAGE directoryOperation )", >>> >>> We have in fact released support for the Relax control, so it's >>> probably time to unifdef these bits and go back to the documented >>> behavior. >> >> That seems reasonable in the long term, though it will break many sites' >> existing password management procedures. The change will have to be >> mentioned in the updated manpage, noting the version at which it takes >> effect. >> >> Should I produce an updated version of the manpage patch? > > Well since you raise the question, what do you think is the more sensible > approach to all of this? I was the one who argued in ldapext that these > attributes should be no-user-modification but perhaps that makes them too > inconvenient to administer. Given the fact that the Relax Rules control still has .666 OID it cannot be used (see my related messages to openldap-devel and ietf-ldapext). At least what's always being said about .666 OIDs... Ciao, Michael.

1 0

Re: ITS#6873
by michael＠stroeder.com 01 Jul '11

01 Jul '11

masarati(a)aero.polimi.it wrote: > Fixed in master, please test. Sorry, last message went to wrong ITS. But also seems to work now...thanks... :-) $ ldapmodify -x -H ldap://localhost:2071 -D "uid=diradm,ou=schulung,dc=stroeder,dc=local" -e relax -w testsecret -f authtime_mod.ldif modifying entry "cn=test1,ou=schulung,dc=stroeder,dc=local" -------------------------- authtime_mod.ldif -------------------------- dn: cn=test1,ou=schulung,dc=stroeder,dc=local changetype: modify replace: authTimestamp authTimestamp: 20110701165029Z

1 0

ITS#6886
by michael＠stroeder.com 01 Jul '11

01 Jul '11

masarati(a)aero.polimi.it wrote: > Fixed in master, please test. Seems to work now...thanks... :-) *** ldap://localhost:2071 - SimpleLDAPObject.extop (('1.3.6.1.4.1.1466.101.119.1', '0/\x80)cn=test1,ou=schulung,dc=stroeder,dc=local\x81\x02\x1c ', None, None),{}) => result: 2 *** ldap://localhost:2071 - SimpleLDAPObject.result4 ((2, 1, -1, 1, 1, 1),{}) => result: (120, [], 2, [], '1.3.6.1.4.1.1466.101.119.1', '0\x04\x81\x02\x1c ') Response TTL: 7200

1 0

Re: ITS#6873
by michael＠stroeder.com 01 Jul '11

01 Jul '11

masarati(a)aero.polimi.it wrote: > Fixed in master, please test. Seems to work now...thanks... :-) *** ldap://localhost:2071 - SimpleLDAPObject.extop (('1.3.6.1.4.1.1466.101.119.1', '0/\x80)cn=test1,ou=schulung,dc=stroeder,dc=local\x81\x02\x1c ', None, None),{}) => result: 2 *** ldap://localhost:2071 - SimpleLDAPObject.result4 ((2, 1, -1, 1, 1, 1),{}) => result: (120, [], 2, [], '1.3.6.1.4.1.1466.101.119.1', '0\x04\x81\x02\x1c ') Response TTL: 7200

1 0

(ITS#6982) libutil md5 incorrect sizeof
by quanah＠OpenLDAP.org 01 Jul '11

01 Jul '11

Full_Name: Quanah Gibson-Mount Version: 2.4.25 OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.45.108) Line 188 in liblutil/md5.c is wrong. It has: memset(ctx, '\0', sizeof(ctx)); /* In case it's sensitive */ It should be: memset(ctx, '\0', sizeof(*ctx)); /* In case it's sensitive */

1 0

ITS#6886
by masarati＠aero.polimi.it 30 Jun '11

30 Jun '11

(should be) fixed in master, please test. p.

1 0

ITS#6873
by masarati＠aero.polimi.it 30 Jun '11

30 Jun '11

Fixed in master, please test. p.

1 0

Re: (ITS#6925) [PATCH] Use inet_ntop for server when available
by Pierangelo Masarati 30 Jun '11

30 Jun '11

Please provide patch as a file, not embedded in email. Upload instructions here <http://www.openldap.org/devel/contributing.html#submitting>. p.

1 0

"database monitor" documentation
by Dan Pritts 30 Jun '11

30 Jun '11

Hi, Looking for docs for the monitor datbase backend, i found this: http://www.openldap.org/devel/admin/monitoringslapd.html Like most other database backends, the monitor backend does honor slapd(8) access and other administrative controls. As some monitor information may be sensitive, it is generally recommend access to cn=monitor be restricted to directory administrators and their monitoring agents. Adding an access directive immediately below the database monitor directive is a clear and effective approach for controlling access. For instance, the addition of the following access directive immediately below the database monitor directive restricts access to monitoring information to the specified directory manager. access to * by dn.exact="cn=Manager,dc=example,dc=com by * none I have misunderstood acl and database config before, but I assume that the ACL here is in error, and something like this from slapd-monitor(5) is appropriate: access to dn.subtree="cn=Monitor" by dn.exact="uid=Admin,dc=my,dc=org" write by users read by * none Assuming I'm correct please update the web docs & let me know. thanks! danno -- Dan Pritts, Sr. Systems Engineer Internet2 office: +1-734-352-4953 | mobile: +1-734-834-7224

2 1

Re: (ITS#6830) slapo-ppolicy.5 has incorrect schema fragments
by andrew.findlay＠skills-1st.co.uk 30 Jun '11

30 Jun '11

On Thu, Jun 30, 2011 at 03:11:05AM -0700, Howard Chu wrote: > Well since you raise the question, what do you think is the more > sensible approach to all of this? I was the one who argued in > ldapext that these attributes should be no-user-modification but > perhaps that makes them too inconvenient to administer. I think that the best approach would be to make no change in 2.4 code but to flag in the docs that the behaviour will change for 2.5. The NO-USER-MODIFICATION flags have been in draft-behera since 2005, but draft-zeilenga-ldap-relax has only been around since 2007. The latter document says that rules may not be relaxed unless there is a document saying that they may be. pwdAccountLockedTime is not mentioned in draft-zeilenga-ldap-relax and the relax control is not mentioned in draft-behera-ldap-password-policy, so one of those docs needs updating to make the behaviour legal. It would be interesting to survey other LDAP implementations to see how they currently treat the password-policy attributes. This is already a minefield due to uncertainties and variations in the replication process. Andrew -- ----------------------------------------------------------------------- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/ +44 1628 782565 | -----------------------------------------------------------------------

1 0

Re: (ITS#6830) slapo-ppolicy.5 has incorrect schema fragments
by hyc＠symas.com 30 Jun '11

30 Jun '11

Andrew Findlay wrote: > On Thu, Jun 09, 2011 at 01:45:17AM -0700, Howard Chu wrote: > >> I note that in ppolicy.c we have: >> >> { "( 1.3.6.1.4.1.42.2.27.8.1.17 " >> "NAME ( 'pwdAccountLockedTime' ) " >> "DESC 'The time an user account was locked' " >> "EQUALITY generalizedTimeMatch " >> "ORDERING generalizedTimeOrderingMatch " >> "SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 " >> "SINGLE-VALUE " >> #if 0 >> /* Not until Relax control is released */ >> "NO-USER-MODIFICATION " >> #endif >> "USAGE directoryOperation )", >> >> We have in fact released support for the Relax control, so it's >> probably time to unifdef these bits and go back to the documented >> behavior. > > That seems reasonable in the long term, though it will break many sites' > existing password management procedures. The change will have to be > mentioned in the updated manpage, noting the version at which it takes > effect. > > Should I produce an updated version of the manpage patch? Well since you raise the question, what do you think is the more sensible approach to all of this? I was the one who argued in ldapext that these attributes should be no-user-modification but perhaps that makes them too inconvenient to administer. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#6981) slapd crashes when using sssvlv and pcache overlays
by ctcard＠hotmail.com 30 Jun '11

30 Jun '11

Full_Name: Chris Card Version: HEAD as of 28 Jun 2011 OS: centos 5.4 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (91.194.158.133) I am running slapd with pcache and sssvlv overlays and back-sql backend. With an empty cache, when I do a request like this: ldapsearch -h localhost -x -b "............" -D "............" -w ........ '(o=.....)' -E \!sss=mail:CaseIgnoreIA5Match slapd crashes in pcache_op_cleanup(), line 2369: /* check for malformed entries: attrs with no values */ { Attribute *a = rs->sr_entry->e_attrs; /* <-- HERE */ because rs->sr_entry is NULL. This appears to be because of the call to rs_flush_entry() in result.c line 1408 which sets rs->sr_entry to NULL prior to the call to pcache_op_cleanup(). The relevant part of my slapd.conf looks like this: database sql suffix "......" rootdn "......" rootpw ...... dbname MySQL dbuser ...... subtree_cond "ldap_entries.dn like CONCAT('%',?)" insentry_stmt "INSERT INTO ldap_entries (dn,oc_map_id,parent,keyval) VALUES (?,?,?,?)" has_ldapinfo_dn_ru no baseobject upper_func UPPER autocommit yes overlay pcache pcache bdb 10000 1 50 100 pcacheAttrset 0 * + pcacheTemplate (objectClass=) 0 60 pcacheTemplate (o=) 0 60 ... pcache-directory /var/tmp/cache pcache-cachesize 100 pcache-index objectClass eq,pres overlay sssvlv sssvlv-max 10 sssvlv-maxpercon 5

1 0

Re: (ITS#6830) slapo-ppolicy.5 has incorrect schema fragments
by andrew.findlay＠skills-1st.co.uk 30 Jun '11

30 Jun '11

On Thu, Jun 09, 2011 at 01:45:17AM -0700, Howard Chu wrote: > I note that in ppolicy.c we have: > > { "( 1.3.6.1.4.1.42.2.27.8.1.17 " > "NAME ( 'pwdAccountLockedTime' ) " > "DESC 'The time an user account was locked' " > "EQUALITY generalizedTimeMatch " > "ORDERING generalizedTimeOrderingMatch " > "SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 " > "SINGLE-VALUE " > #if 0 > /* Not until Relax control is released */ > "NO-USER-MODIFICATION " > #endif > "USAGE directoryOperation )", > > We have in fact released support for the Relax control, so it's > probably time to unifdef these bits and go back to the documented > behavior. That seems reasonable in the long term, though it will break many sites' existing password management procedures. The change will have to be mentioned in the updated manpage, noting the version at which it takes effect. Should I produce an updated version of the manpage patch? Andrew -- ----------------------------------------------------------------------- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/ +44 1628 782565 | -----------------------------------------------------------------------

1 0

(ITS#6980) Patch - Mozilla NSS - memleak - have to free the return from SSL_PeerCertificate
by rmeggins＠redhat.com 29 Jun '11

29 Jun '11

Full_Name: Rich Megginson Version: 2.4.25 (current CVS HEAD) OS: RHEL6 URL: ftp://ftp.openldap.org/incoming/openldap-2.4.25-moznss-free-return-of-SSL_P… Submission from: (NULL) (76.113.106.30) In tlsm_auth_cert_handler, we get the peer's cert from the socket using SSL_PeerCertificate. This value is allocated and/or cached. We must destroy it using CERT_DestroyCertificate. These patch files are derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Red Hat. Red Hat has not assigned rights and/or interest in this work to any party. I, Rich Megginson am authorized by Red Hat, my employer, to release this work under the following terms. Red Hat hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.

1 0

Re: (ITS#6828) TLS fails to start when LDAP_OPT_CONNECT_ASYNC is used
by hyc＠symas.com 27 Jun '11

27 Jun '11

Ian Puleston wrote: > There is something missing from the fix. I just had a problem where an asynchronous connect was failing and the result was continuous looping with repeated calls to ldap_sasl_bind. > > The problem is that if the connect fails, ldap_int_poll called from ldap_int_check_async_open gets an error and returns -1, and then -1 is returned up the stack ldap_int_check_async_open -> ldap_send_initial_request -> ldap_sasl_bind. But when ldap_sasl_bind gets that -1 return from ldap_send_initial_request it returns ld->ld_errno, and nowhere have we set that. In fact, ld->ld_errno still contains LDAP_X_CONNECTING from when the initial connect was issued, and so ldap_sasl_bind returns LDAP_X_CONNECTING, and that is what leads to the infinite looping that I see. Thanks for the analysis and fix. Now patched in master. In the future please send actual diffs, as noted http://www.openldap.org/devel/contributing.html > What is missing is that in ldap_int_check_async_open this: > > default: > return -1; > > Should be changed to: > > default: > ld->ld_errno = LDAP_CONNECT_ERROR; > return -1; > > Ian -- -- 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#6828) TLS fails to start when LDAP_OPT_CONNECT_ASYNC is used
by ipuleston＠SonicWALL.com 27 Jun '11

27 Jun '11

There is something missing from the fix. I just had a problem where an asynchronous connect was failing and the result was continuous looping with repeated calls to ldap_sasl_bind. The problem is that if the connect fails, ldap_int_poll called from ldap_int_check_async_open gets an error and returns -1, and then -1 is returned up the stack ldap_int_check_async_open -> ldap_send_initial_request -> ldap_sasl_bind. But when ldap_sasl_bind gets that -1 return from ldap_send_initial_request it returns ld->ld_errno, and nowhere have we set that. In fact, ld->ld_errno still contains LDAP_X_CONNECTING from when the initial connect was issued, and so ldap_sasl_bind returns LDAP_X_CONNECTING, and that is what leads to the infinite looping that I see. What is missing is that in ldap_int_check_async_open this: default: return -1; Should be changed to: default: ld->ld_errno = LDAP_CONNECT_ERROR; return -1; Ian

1 0

Re: (ITS#6870) Undefined reference to ber_* with 2.4.24
by jvcelak＠redhat.com 27 Jun '11

27 Jun '11

LDIF functionality is included in libldif, but the interface is not provided (ldif.h is not installed by make install). This happens for RE24 branch, master branch is fine. Patch: ftp://ftp.openldap.org/incoming/jvcelak-20110627-export-ldif-h.patch Jan

1 0

RE: (ITS#6828) TLS fails to start when LDAP_OPT_CONNECT_ASYNC is used
by ipuleston＠SonicWALL.com 24 Jun '11

24 Jun '11

Thanks Howard. I pulled your change out of GIT and tested it, and it works fine for me. However, just as an FYI, this line in open.c results in a "suggest parentheses around && within ||" warning from gcc with the compiler options that we use to compile our OpenLDAP port, and that in turn results in a build failure (since we use -Werror): if (rc == 0 && ld->ld_options.ldo_tls_mode == LDAP_OPT_X_TLS_HARD || strcmp( srv->lud_scheme, "ldaps" ) == 0 ) The parentheses that I had in that line in my patch avoided that. Ian

1 0

Re: (ITS#6828) TLS fails to start when LDAP_OPT_CONNECT_ASYNC is used
by hyc＠symas.com 24 Jun '11

24 Jun '11

Ian Puleston wrote: >> -----Original Message----- >> From: Howard Chu [mailto:hyc@symas.com] >> Sent: Wednesday, June 08, 2011 5:47 PM >> >> I'm pretty sure that this chunk can never do anything useful. >> ... >> The connection has just been created, asynchronously, so there's no way >> that >> the TLS layer was already started when it got here. > > After re-reviewing it I think you are correct. I put that in because I thought there may be a chance that ldap_int_tls_start could get called from ldap_int_open_connection if the connect completed very quickly in the underlying layers. But even if it did there has been no call to ldap_int_poll to check for it having completed. ldap_pvt_connect and then ldap_connect_to_host return -2 to ldap_int_open_connection on an async connect. And the latter then only calls ldap_int_tls_start if rc == 0, so that call will not happen. > >> Also, I suggest that you only check for CONNST_CONNECTING in the >> callers, and do the TLS check in the check function > > Yes, good idea. I guess that the way I have it allows it to start up TLS immediately if using TLS and the connect completes immediately, but if not using TLS it will return LDAP_X_CONNECTING. What you are suggesting means that if not using TLS and the connect completes immediately then it will be able to go ahead and send the request rather than retuning LDAP_X_CONNECTING. > > I will update the fix and supply a new patch shortly. No need, I already committed a fix to git. It is also in RE24. > > Thanks > Ian > > > > > > > -- -- 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#6828) TLS fails to start when LDAP_OPT_CONNECT_ASYNC is used
by ipuleston＠SonicWALL.com 24 Jun '11

24 Jun '11

> -----Original Message----- > From: Howard Chu [mailto:hyc@symas.com] > Sent: Wednesday, June 08, 2011 5:47 PM > > I'm pretty sure that this chunk can never do anything useful. > ... > The connection has just been created, asynchronously, so there's no way > that > the TLS layer was already started when it got here. After re-reviewing it I think you are correct. I put that in because I thought there may be a chance that ldap_int_tls_start could get called from ldap_int_open_connection if the connect completed very quickly in the underlying layers. But even if it did there has been no call to ldap_int_poll to check for it having completed. ldap_pvt_connect and then ldap_connect_to_host return -2 to ldap_int_open_connection on an async connect. And the latter then only calls ldap_int_tls_start if rc == 0, so that call will not happen. > Also, I suggest that you only check for CONNST_CONNECTING in the > callers, and do the TLS check in the check function Yes, good idea. I guess that the way I have it allows it to start up TLS immediately if using TLS and the connect completes immediately, but if not using TLS it will return LDAP_X_CONNECTING. What you are suggesting means that if not using TLS and the connect completes immediately then it will be able to go ahead and send the request rather than retuning LDAP_X_CONNECTING. I will update the fix and supply a new patch shortly. Thanks Ian

1 0

Re: (ITS#6978) Invalid indentation of splitted lines in LDIF input file causes SEGFAULT
by jvcelak＠redhat.com 24 Jun '11

24 Jun '11

On Friday 24 June 2011 09:11:41, Howard Chu wrote: > >> There is no file ldifutil.c in OpenLDAP 2.4. > >> > >> I don't know what you're testing against, but this bug report appears > >> invalid. Closing. > > > > $ find -name ldifutil.c > > ./libraries/libldap/ldifutil.c > > ./libraries/libldap_r/ldifutil.c > > > > Tested against git master branch. > > Read again what I wrote. There is no file ldifutil.c in OpenLDAP 2.4. git > master is not the same as the 2.4 releases. Ouch, sorry. Then it is fixed only in master, not in RE24 (7cac590). $ ./ldapmodify -a -x -f /tmp/invalid.ldif -d2048 ldif_parse_line: missing ':' after dc=com ldapmodify: invalid format (line 2) entry: "cn=B,dc=my-domain," Segmentation fault (core dumped) (gdb) bt #0 __strcasecmp_l_ssse3 () at ../sysdeps/x86_64/strcmp.S:214 #1 0x000000000040789c in process_ldif_rec (rbuf=0x67464e "objectclass: inetOrgPerson\nobjectclass: organizationalPerson\nobjectclass: person\nobjectclass: top\ncn: B\nsn: B\nuid: B\nmail: b(a)example.org\n", linenum=1) at ldapmodify.c:655 #2 0x00000000004067d5 in main (argc=6, argv=0x7fffffffdd88) at ldapmodify.c:335

1 0

Re: (ITS#6978) Invalid indentation of splitted lines in LDIF input file causes SEGFAULT
by hyc＠symas.com 24 Jun '11

24 Jun '11

Jan Vcelak wrote: > On Thursday 23 June 2011 22:41:20, Howard Chu wrote: >> jvcelak(a)redhat.com wrote: >>> Full_Name: Jan Vcelak >>> Version: 2.5.25 >> >> There is no OpenLDAP version 2.5. > > This is a typo. I mean 2.4.25. (But it an older issue, it was reported in RH > bugzilla against 2.4.23.) > >> There is no file ldifutil.c in OpenLDAP 2.4. >> >> I don't know what you're testing against, but this bug report appears >> invalid. Closing. > > $ find -name ldifutil.c > ./libraries/libldap/ldifutil.c > ./libraries/libldap_r/ldifutil.c > > Tested against git master branch. Read again what I wrote. There is no file ldifutil.c in OpenLDAP 2.4. git master is not the same as the 2.4 releases. >> Your example doesn't SEGV for me. Anyway, I've committed a different patch >> to master for this issue. > > Strange... Fedora Linux 15, 64bit. And clearly an uninitialized memory was > accessed. But your fix is fine and works for me. > > Thank you. > > Jan > -- -- 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#6978) Invalid indentation of splitted lines in LDIF input file causes SEGFAULT
by jvcelak＠redhat.com 24 Jun '11

24 Jun '11

On Thursday 23 June 2011 22:41:20, Howard Chu wrote: > jvcelak(a)redhat.com wrote: > > Full_Name: Jan Vcelak > > Version: 2.5.25 > > There is no OpenLDAP version 2.5. This is a typo. I mean 2.4.25. (But it an older issue, it was reported in RH bugzilla against 2.4.23.) > There is no file ldifutil.c in OpenLDAP 2.4. > > I don't know what you're testing against, but this bug report appears > invalid. Closing. $ find -name ldifutil.c ./libraries/libldap/ldifutil.c ./libraries/libldap_r/ldifutil.c Tested against git master branch. > Your example doesn't SEGV for me. Anyway, I've committed a different patch > to master for this issue. Strange... Fedora Linux 15, 64bit. And clearly an uninitialized memory was accessed. But your fix is fine and works for me. Thank you. Jan

1 0

Re: (ITS#6977) ldapwhoami minor verbose bugfix patch submission
by hyc＠symas.com 23 Jun '11

23 Jun '11

hyc(a)symas.com wrote: > checker(a)d6.com wrote: >> Full_Name: Chris Hecker >> Version: 2.4.25 >> OS: centos 5.6 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (98.248.126.162) >> >> >> Hi, ldapwhoami erroneously prints the "Result: Success (0)" string even if -v is >> not specified due to a minor bug in the code. Here is a fix. I am running >> 2.3.43, but just checked the latest repository version and the bug is still >> there (although at line 203 now), so I marked the version above as latest. >> >> Thanks, >> Chris > > It seems to me the better fix would be to change ldap_parse_result() to not > populate matcheddn or text when their values are zero-length. Kurt, any > particular reason things should continue to work as they currently do? OK, they work according to the C API draft. (sigh.) Client tools patched in 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#6977) ldapwhoami minor verbose bugfix patch submission
by checker＠d6.com 23 Jun '11

23 Jun '11

Yeah, I just decided to do the same test as the two enclosed if statements to be 100% compatible. Chris On 2011/06/23 13:31, Howard Chu wrote: > checker(a)d6.com wrote: >> Full_Name: Chris Hecker >> Version: 2.4.25 >> OS: centos 5.6 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (98.248.126.162) >> >> >> Hi, ldapwhoami erroneously prints the "Result: Success (0)" string >> even if -v is >> not specified due to a minor bug in the code. Here is a fix. I am running >> 2.3.43, but just checked the latest repository version and the bug is >> still >> there (although at line 203 now), so I marked the version above as >> latest. >> >> Thanks, >> Chris > > It seems to me the better fix would be to change ldap_parse_result() to > not populate matcheddn or text when their values are zero-length. Kurt, > any particular reason things should continue to work as they currently do? > >> >> --- old/openldap-2.3.43/clients/tools/ldapwhoami.c 2008-02-11 >> 17:24:07.000000000 -0600 >> +++ openldap-2.3.43/clients/tools/ldapwhoami.c 2011-06-21 >> 14:15:28.000000000 >> -0500 >> @@ -215,7 +215,7 @@ >> >> skip: >> if ( verbose || ( code != LDAP_SUCCESS ) || >> - matcheddn || text || refs || ctrls ) >> + (matcheddn&& *matcheddn) || (text&& *text) || refs || ctrls ) >> { >> printf( _("Result: %s (%d)\n"), ldap_err2string( code ), code >> ); >> >> >> > >

1 0

Re: (ITS#6978) Invalid indentation of splitted lines in LDIF input file causes SEGFAULT
by hyc＠symas.com 23 Jun '11

23 Jun '11

jvcelak(a)redhat.com wrote: > Full_Name: Jan Vcelak > Version: 2.5.25 There is no OpenLDAP version 2.5. > OS: Linux > URL: ftp://ftp.openldap.org/incoming/jvcelak-20110622-ldif-split-indent-segfault… > Submission from: (NULL) (209.132.186.34) > > > Hello, > > input LDIF file with splitted lines which are indented incorrectly causes > SEGFAULT of a client tool. Let me show: > > $ cat /tmp/invalid.ldif > dn: cn=B,dc=my-domain, > dc=com > objectclass: inetOrgPerson > objectclass: organizationalPerson > objectclass: person > objectclass: top > cn: B > sn: B > uid: B > mail: b(a)example.org > > $ ldapmodify -a -x -f /tmp/invalid.ldif -d2048 > ldif_parse_line: missing ':' after dc=com > ldapmodify: invalid format (line 2) entry: "cn=B,dc=my-domain," > Segmentation fault (core dumped) > > > (gdb) bt full > #0 __strcasecmp_l_ssse3 () at ../sysdeps/x86_64/strcmp.S:214 > No locals. > #1 0x000000000042d9f3 in ldap_parse_ldif_record_x (rbuf=0x7fffffffdbb0, > linenum=1, lr=0x7fffffffdb30, errstr=0x7fffffffe197 "ldapmodify", flags=1, > ctx=0x0) at ldifutil.c:399 There is no file ldifutil.c in OpenLDAP 2.4. I don't know what you're testing against, but this bug report appears invalid. Closing. > fv = 0 > line = 0x668627 "dc=com" > dn = 0x668614 "cn=B,dc=my-domain," > rc = -9 > modop = 0 > expect_modop = 0 > expect_sep = 0 > ldapadd = 1 > new_entry = 1 > delete_entry = 0 > got_all = 0 > pmods = 0x6697e8 > version = 0 > pctrls = 0x0 > i = 1 > j = 0 > k = -1 > idn = 1 > nmods = 1 > bvl = 0x6697f8 > bv = {bv_len = 0, bv_val = 0x0} > __PRETTY_FUNCTION__ = "ldap_parse_ldif_record_x" > #2 0x000000000042e524 in ldap_parse_ldif_record (rbuf=0x7fffffffdbb0, > linenum=1, lr=0x7fffffffdb30, errstr=0x7fffffffe197 "ldapmodify", flags=1) at > ldifutil.c:565 > No locals. > #3 0x0000000000406ff8 in process_ldif_rec (rbuf=0x668610 "dn", linenum=1) at > ldapmodify.c:404 > lr = {lr_op = 0, lr_dn = {bv_len = 18, bv_val = 0x668614 > "cn=B,dc=my-domain,"}, lr_ctrls = 0x0, ldif_ops = {lr_mods = 0x0, ldif_op_rename > = {lr_newrdn = {bv_len = 0, > bv_val = 0x0}, lr_newsuperior = {bv_len = 0, bv_val = 0x0}, > lr_deleteoldrdn = 0}, ldif_op_ext = {lr_extop_oid = {bv_len = 0, bv_val = 0x0}, > lr_extop_data = { > bv_len = 0, bv_val = 0x0}}, ldif_op_cmp = {lr_cmp_attr = {bv_len > = 0, bv_val = 0x0}, lr_cmp_bvalue = {bv_len = 0, bv_val = 0x0}}}, lr_ctx = 0x0, > lr_lines = 2, > lr_lm = 0x6697d0, lr_mops = 0x0, lr_freeval = 0x6699e0 "", lr_vals = > 0x669930, lr_btype = 0x669880} > lrflags = 1 > rc = 0 > rbuf_bv = {bv_len = 0, > bv_val = 0x66862e "objectclass: inetOrgPerson\nobjectclass: > organizationalPerson\nobjectclass: person\nobjectclass: top\ncn: B\nsn: B\nuid: > B\nmail: b(a)example.org\n"} > #4 0x0000000000406cb7 in main (argc=6, argv=0x7fffffffdd98) at > ldapmodify.c:316 > rbuf = 0x668610 "dn" > rejbuf = 0x0 > rejfp = 0x0 > ldiffp = 0x6600a0 > ldifdummy = {fp = 0x0, prev = 0x0} > matched_msg = 0x448790 "H\211l$\330L\211d$\340H\215-\003\060!" > error_msg = 0x8000<Address 0x8000 out of bounds> > rc = 0 > retval = 0 > ldifrc = 1 > len = 4491152 > i = 0 > lineno = 1 > nextline = 11 > lmax = 4119 > c = {{ldctl_oid = 0x7fe0f05<Address 0x7fe0f05 out of bounds>, > ldctl_value = {bv_len = 5044973646, bv_val = 0x0}, ldctl_iscritical = 0 > '\000'}} > (gdb) frame 1 > #1 0x000000000042d9f3 in ldap_parse_ldif_record_x (rbuf=0x7fffffffdbb0, > linenum=1, lr=0x7fffffffdb30, errstr=0x7fffffffe197 "ldapmodify", flags=1, > ctx=0x0) at ldifutil.c:399 > 399 if ( !BV_CASEMATCH( lr->lr_btype+i,&bv )) { > (gdb) p *(lr->lr_btype+1) > $1 = {bv_len = 0, bv_val = 0x668627 "dc=com"} > (gdb) > > bv_len is set incorrectly to zero and therefore the string will be compared > against bv, which is a "null string". > > I have uploaded patch to address this issue. > > With the patch applied, the output is following: > > ./ldapmodify -a -x -f /tmp/invalid.ldif -d2048 > ldif_parse_line: missing ':' after dc=com > ldapmodify: invalid format (line 2) entry: "cn=B,dc=my-domain," > > -- -- 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#6977) ldapwhoami minor verbose bugfix patch submission
by hyc＠symas.com 23 Jun '11

23 Jun '11

checker(a)d6.com wrote: > Full_Name: Chris Hecker > Version: 2.4.25 > OS: centos 5.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (98.248.126.162) > > > Hi, ldapwhoami erroneously prints the "Result: Success (0)" string even if -v is > not specified due to a minor bug in the code. Here is a fix. I am running > 2.3.43, but just checked the latest repository version and the bug is still > there (although at line 203 now), so I marked the version above as latest. > > Thanks, > Chris It seems to me the better fix would be to change ldap_parse_result() to not populate matcheddn or text when their values are zero-length. Kurt, any particular reason things should continue to work as they currently do? > > --- old/openldap-2.3.43/clients/tools/ldapwhoami.c 2008-02-11 > 17:24:07.000000000 -0600 > +++ openldap-2.3.43/clients/tools/ldapwhoami.c 2011-06-21 14:15:28.000000000 > -0500 > @@ -215,7 +215,7 @@ > > skip: > if ( verbose || ( code != LDAP_SUCCESS ) || > - matcheddn || text || refs || ctrls ) > + (matcheddn&& *matcheddn) || (text&& *text) || refs || ctrls ) > { > printf( _("Result: %s (%d)\n"), ldap_err2string( code ), code > ); > > > -- -- 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#6978) Invalid indentation of splitted lines in LDIF input file causes SEGFAULT
by hyc＠symas.com 23 Jun '11

23 Jun '11

jvcelak(a)redhat.com wrote: > Full_Name: Jan Vcelak > Version: 2.5.25 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/jvcelak-20110622-ldif-split-indent-segfault… > Submission from: (NULL) (209.132.186.34) > > > Hello, > > input LDIF file with splitted lines which are indented incorrectly causes > SEGFAULT of a client tool. Let me show: Your example doesn't SEGV for me. Anyway, I've committed a different patch to master for this issue. > > $ cat /tmp/invalid.ldif > dn: cn=B,dc=my-domain, > dc=com > objectclass: inetOrgPerson > objectclass: organizationalPerson > objectclass: person > objectclass: top > cn: B > sn: B > uid: B > mail: b(a)example.org > > $ ldapmodify -a -x -f /tmp/invalid.ldif -d2048 > ldif_parse_line: missing ':' after dc=com > ldapmodify: invalid format (line 2) entry: "cn=B,dc=my-domain," > Segmentation fault (core dumped) > > > (gdb) bt full > #0 __strcasecmp_l_ssse3 () at ../sysdeps/x86_64/strcmp.S:214 > No locals. > #1 0x000000000042d9f3 in ldap_parse_ldif_record_x (rbuf=0x7fffffffdbb0, > linenum=1, lr=0x7fffffffdb30, errstr=0x7fffffffe197 "ldapmodify", flags=1, > ctx=0x0) at ldifutil.c:399 > fv = 0 > line = 0x668627 "dc=com" > dn = 0x668614 "cn=B,dc=my-domain," > rc = -9 > modop = 0 > expect_modop = 0 > expect_sep = 0 > ldapadd = 1 > new_entry = 1 > delete_entry = 0 > got_all = 0 > pmods = 0x6697e8 > version = 0 > pctrls = 0x0 > i = 1 > j = 0 > k = -1 > idn = 1 > nmods = 1 > bvl = 0x6697f8 > bv = {bv_len = 0, bv_val = 0x0} > __PRETTY_FUNCTION__ = "ldap_parse_ldif_record_x" > #2 0x000000000042e524 in ldap_parse_ldif_record (rbuf=0x7fffffffdbb0, > linenum=1, lr=0x7fffffffdb30, errstr=0x7fffffffe197 "ldapmodify", flags=1) at > ldifutil.c:565 > No locals. > #3 0x0000000000406ff8 in process_ldif_rec (rbuf=0x668610 "dn", linenum=1) at > ldapmodify.c:404 > lr = {lr_op = 0, lr_dn = {bv_len = 18, bv_val = 0x668614 > "cn=B,dc=my-domain,"}, lr_ctrls = 0x0, ldif_ops = {lr_mods = 0x0, ldif_op_rename > = {lr_newrdn = {bv_len = 0, > bv_val = 0x0}, lr_newsuperior = {bv_len = 0, bv_val = 0x0}, > lr_deleteoldrdn = 0}, ldif_op_ext = {lr_extop_oid = {bv_len = 0, bv_val = 0x0}, > lr_extop_data = { > bv_len = 0, bv_val = 0x0}}, ldif_op_cmp = {lr_cmp_attr = {bv_len > = 0, bv_val = 0x0}, lr_cmp_bvalue = {bv_len = 0, bv_val = 0x0}}}, lr_ctx = 0x0, > lr_lines = 2, > lr_lm = 0x6697d0, lr_mops = 0x0, lr_freeval = 0x6699e0 "", lr_vals = > 0x669930, lr_btype = 0x669880} > lrflags = 1 > rc = 0 > rbuf_bv = {bv_len = 0, > bv_val = 0x66862e "objectclass: inetOrgPerson\nobjectclass: > organizationalPerson\nobjectclass: person\nobjectclass: top\ncn: B\nsn: B\nuid: > B\nmail: b(a)example.org\n"} > #4 0x0000000000406cb7 in main (argc=6, argv=0x7fffffffdd98) at > ldapmodify.c:316 > rbuf = 0x668610 "dn" > rejbuf = 0x0 > rejfp = 0x0 > ldiffp = 0x6600a0 > ldifdummy = {fp = 0x0, prev = 0x0} > matched_msg = 0x448790 "H\211l$\330L\211d$\340H\215-\003\060!" > error_msg = 0x8000<Address 0x8000 out of bounds> > rc = 0 > retval = 0 > ldifrc = 1 > len = 4491152 > i = 0 > lineno = 1 > nextline = 11 > lmax = 4119 > c = {{ldctl_oid = 0x7fe0f05<Address 0x7fe0f05 out of bounds>, > ldctl_value = {bv_len = 5044973646, bv_val = 0x0}, ldctl_iscritical = 0 > '\000'}} > (gdb) frame 1 > #1 0x000000000042d9f3 in ldap_parse_ldif_record_x (rbuf=0x7fffffffdbb0, > linenum=1, lr=0x7fffffffdb30, errstr=0x7fffffffe197 "ldapmodify", flags=1, > ctx=0x0) at ldifutil.c:399 > 399 if ( !BV_CASEMATCH( lr->lr_btype+i,&bv )) { > (gdb) p *(lr->lr_btype+1) > $1 = {bv_len = 0, bv_val = 0x668627 "dc=com"} > (gdb) > > bv_len is set incorrectly to zero and therefore the string will be compared > against bv, which is a "null string". > > I have uploaded patch to address this issue. > > With the patch applied, the output is following: > > ./ldapmodify -a -x -f /tmp/invalid.ldif -d2048 > ldif_parse_line: missing ':' after dc=com > ldapmodify: invalid format (line 2) entry: "cn=B,dc=my-domain," > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#6979) test062 portability
by richton＠nbcs.rutgers.edu 23 Jun '11

23 Jun '11

Full_Name: Aaron Richton Version: RE24 OS: irrelevant URL: Submission from: (NULL) (166.217.78.192) It looks like checking the function exit isn't portable; maybe some kind of bash-ism. It looks like the code was on the path to communicating the retval via $RCOUT file already? As such, here's one quick workaround, although I'd love something a bit more elegant: --- test062-config-delete~ 2011-06-23 07:21:01.387583000 -0400 +++ test062-config-delete 2011-06-23 07:21:14.884787000 -0400 @@ -106,7 +106,7 @@ ( $LDAPSEARCH -D cn=config -H $URI1 -y $CONFIGPWF -bcn=config -E \!sync=rp >/dev/null 2>&1 RC=$? - touch $RCOUT + echo $RC > $RCOUT exit $RC ) & @@ -137,7 +137,7 @@ if test -f "$RCOUT" ; then wait $SEARCHPID - SEARCHRC=$? + SEARCHRC=`cat $RCOUT` echo "Checking return code of backgrounded RefreshAndPersist search ..." if test $SEARCHRC != 52 ; then echo "Error: Backgrounded ldapsearch did return the wrong error code: $SEARCHRC"

1 0

(ITS#6978) Invalid indentation of splitted lines in LDIF input file causes SEGFAULT
by jvcelak＠redhat.com 22 Jun '11

22 Jun '11

Full_Name: Jan Vcelak Version: 2.5.25 OS: Linux URL: ftp://ftp.openldap.org/incoming/jvcelak-20110622-ldif-split-indent-segfault… Submission from: (NULL) (209.132.186.34) Hello, input LDIF file with splitted lines which are indented incorrectly causes SEGFAULT of a client tool. Let me show: $ cat /tmp/invalid.ldif dn: cn=B,dc=my-domain, dc=com objectclass: inetOrgPerson objectclass: organizationalPerson objectclass: person objectclass: top cn: B sn: B uid: B mail: b(a)example.org $ ldapmodify -a -x -f /tmp/invalid.ldif -d2048 ldif_parse_line: missing ':' after dc=com ldapmodify: invalid format (line 2) entry: "cn=B,dc=my-domain," Segmentation fault (core dumped) (gdb) bt full #0 __strcasecmp_l_ssse3 () at ../sysdeps/x86_64/strcmp.S:214 No locals. #1 0x000000000042d9f3 in ldap_parse_ldif_record_x (rbuf=0x7fffffffdbb0, linenum=1, lr=0x7fffffffdb30, errstr=0x7fffffffe197 "ldapmodify", flags=1, ctx=0x0) at ldifutil.c:399 fv = 0 line = 0x668627 "dc=com" dn = 0x668614 "cn=B,dc=my-domain," rc = -9 modop = 0 expect_modop = 0 expect_sep = 0 ldapadd = 1 new_entry = 1 delete_entry = 0 got_all = 0 pmods = 0x6697e8 version = 0 pctrls = 0x0 i = 1 j = 0 k = -1 idn = 1 nmods = 1 bvl = 0x6697f8 bv = {bv_len = 0, bv_val = 0x0} __PRETTY_FUNCTION__ = "ldap_parse_ldif_record_x" #2 0x000000000042e524 in ldap_parse_ldif_record (rbuf=0x7fffffffdbb0, linenum=1, lr=0x7fffffffdb30, errstr=0x7fffffffe197 "ldapmodify", flags=1) at ldifutil.c:565 No locals. #3 0x0000000000406ff8 in process_ldif_rec (rbuf=0x668610 "dn", linenum=1) at ldapmodify.c:404 lr = {lr_op = 0, lr_dn = {bv_len = 18, bv_val = 0x668614 "cn=B,dc=my-domain,"}, lr_ctrls = 0x0, ldif_ops = {lr_mods = 0x0, ldif_op_rename = {lr_newrdn = {bv_len = 0, bv_val = 0x0}, lr_newsuperior = {bv_len = 0, bv_val = 0x0}, lr_deleteoldrdn = 0}, ldif_op_ext = {lr_extop_oid = {bv_len = 0, bv_val = 0x0}, lr_extop_data = { bv_len = 0, bv_val = 0x0}}, ldif_op_cmp = {lr_cmp_attr = {bv_len = 0, bv_val = 0x0}, lr_cmp_bvalue = {bv_len = 0, bv_val = 0x0}}}, lr_ctx = 0x0, lr_lines = 2, lr_lm = 0x6697d0, lr_mops = 0x0, lr_freeval = 0x6699e0 "", lr_vals = 0x669930, lr_btype = 0x669880} lrflags = 1 rc = 0 rbuf_bv = {bv_len = 0, bv_val = 0x66862e "objectclass: inetOrgPerson\nobjectclass: organizationalPerson\nobjectclass: person\nobjectclass: top\ncn: B\nsn: B\nuid: B\nmail: b(a)example.org\n"} #4 0x0000000000406cb7 in main (argc=6, argv=0x7fffffffdd98) at ldapmodify.c:316 rbuf = 0x668610 "dn" rejbuf = 0x0 rejfp = 0x0 ldiffp = 0x6600a0 ldifdummy = {fp = 0x0, prev = 0x0} matched_msg = 0x448790 "H\211l$\330L\211d$\340H\215-\003\060!" error_msg = 0x8000 <Address 0x8000 out of bounds> rc = 0 retval = 0 ldifrc = 1 len = 4491152 i = 0 lineno = 1 nextline = 11 lmax = 4119 c = {{ldctl_oid = 0x7fe0f05 <Address 0x7fe0f05 out of bounds>, ldctl_value = {bv_len = 5044973646, bv_val = 0x0}, ldctl_iscritical = 0 '\000'}} (gdb) frame 1 #1 0x000000000042d9f3 in ldap_parse_ldif_record_x (rbuf=0x7fffffffdbb0, linenum=1, lr=0x7fffffffdb30, errstr=0x7fffffffe197 "ldapmodify", flags=1, ctx=0x0) at ldifutil.c:399 399 if ( !BV_CASEMATCH( lr->lr_btype+i, &bv )) { (gdb) p *(lr->lr_btype+1) $1 = {bv_len = 0, bv_val = 0x668627 "dc=com"} (gdb) bv_len is set incorrectly to zero and therefore the string will be compared against bv, which is a "null string". I have uploaded patch to address this issue. With the patch applied, the output is following: ./ldapmodify -a -x -f /tmp/invalid.ldif -d2048 ldif_parse_line: missing ':' after dc=com ldapmodify: invalid format (line 2) entry: "cn=B,dc=my-domain,"

1 0

(ITS#6977) ldapwhoami minor verbose bugfix patch submission
by checker＠d6.com 21 Jun '11

21 Jun '11

Full_Name: Chris Hecker Version: 2.4.25 OS: centos 5.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (98.248.126.162) Hi, ldapwhoami erroneously prints the "Result: Success (0)" string even if -v is not specified due to a minor bug in the code. Here is a fix. I am running 2.3.43, but just checked the latest repository version and the bug is still there (although at line 203 now), so I marked the version above as latest. Thanks, Chris --- old/openldap-2.3.43/clients/tools/ldapwhoami.c 2008-02-11 17:24:07.000000000 -0600 +++ openldap-2.3.43/clients/tools/ldapwhoami.c 2011-06-21 14:15:28.000000000 -0500 @@ -215,7 +215,7 @@ skip: if ( verbose || ( code != LDAP_SUCCESS ) || - matcheddn || text || refs || ctrls ) + (matcheddn && *matcheddn) || (text && *text) || refs || ctrls ) { printf( _("Result: %s (%d)\n"), ldap_err2string( code ), code );

1 0

Re: (ITS#6976) Build OpenLDAP on Solaris : error : could not locate usable POSIX Threads
by Howard Chu 21 Jun '11

21 Jun '11

The ITS is for actual bugs in the software. This looks like a misconfiguration in your build environment, not an OpenLDAP bug. You should ask for help on the openldap-technical mailing list instead.

1 0

Re: (ITS#6973) Problem with sssvlv overlay and ldapsearch
by hyc＠symas.com 21 Jun '11

21 Jun '11

ctcard(a)hotmail.com wrote: >> Don't send HTML emails to the ITS.Apologies. >> >> I'm unable to reproduce the error you're talking about. Please provide a >> config that demonstrates the error, and the complete ldapsearch command >> invocation. > The original submission contained the ldapsearch command: > ldapsearch -h localhost -x -b "..........." -D ".........." -w .... -E > \!sss=mail:caseIgnoreIA5Match -E \!vlv=0/10/0/10 I also asked for a server config that demonstrates the problem. When you omit key details, particularly when they are specificly requested, you only slow down the troubleshooting process. From your description in this email, I'm guessing that you've configured sssvlv as a global overlay instead of on a specific database. That's why the overlay is running before fe_op_search. I was testing with the overlay on a specific database. You should probably change your server configuration as a workaround until this gets patched. > (I just suppressed the bind dn, base dn and password) > The important aspect of the search command is that it is doing a server-sidesort on the mail attribute, is asking for a virtual list view, but is letting the size default to zero (which should mean unlimited). >> >> Your patch cannot be correct since limits_check() is already called by the >> frontend at the beginning of every search operation. > > Not in my experience. > As far as I can see limits_check() is called only in fe_op_search() in search.c, and when debugging I found that fe_op_search() was being called from overlay_op_walk() in backover.c. > > When the ldapsearch command is run, it sends a search request to slapd, which returns the first 11 records found, in order of the mail attribute. Then ldapsearch prompts > Press [before/after(/offset/count|:value)] Enter for the next window. > and on hitting enter ldapsearch sends the next request to slapd. This time the request gets handled by sssvlv_op_search() before fe_op_search() is called, because there is an active session. > int overlay_op_walk( Operation *op, SlapReply *rs, slap_operation_t which, slap_overinfo *oi, slap_overinst *on){ BI_op_bind **func; int rc = SLAP_CB_CONTINUE; > for (; on; on=on->on_next ) { func =&on->on_bi.bi_op_bind; if ( func[which] ) { op->o_bd->bd_info = (BackendInfo *)on; rc = func[which]( op, rs ); /*<--- sssvlv_op_search() called here */ if ( rc != SLAP_CB_CONTINUE ) break; } } if ( rc == SLAP_CB_BYPASS ) rc = SLAP_CB_CONTINUE; > func =&oi->oi_orig->bi_op_bind; if ( func[which]&& rc == SLAP_CB_CONTINUE ) { op->o_bd->bd_info = oi->oi_orig; rc = func[which]( op, rs ); /*<--- fe_op_search() called here */ } > 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#6973) Problem with sssvlv overlay and ldapsearch
by ctcard＠hotmail.com 21 Jun '11

21 Jun '11

> Don't send HTML emails to the ITS.Apologies. > > I'm unable to reproduce the error you're talking about. Please provide a > config that demonstrates the error, and the complete ldapsearch command > invocation. The original submission contained the ldapsearch command: ldapsearch -h localhost -x -b "..........." -D ".........." -w .... -E \!sss=mail:caseIgnoreIA5Match -E \!vlv=0/10/0/10 (I just suppressed the bind dn, base dn and password) The important aspect of the search command is that it is doing a server-sidesort on the mail attribute, is asking for a virtual list view, but is letting the size default to zero (which should mean unlimited). > > Your patch cannot be correct since limits_check() is already called by the > frontend at the beginning of every search operation. Not in my experience. As far as I can see limits_check() is called only in fe_op_search() in search.c, and when debugging I found that fe_op_search() was being called from overlay_op_walk() in backover.c. When the ldapsearch command is run, it sends a search request to slapd, which returns the first 11 records found, in order of the mail attribute. Then ldapsearch prompts Press [before/after(/offset/count|:value)] Enter for the next window. and on hitting enter ldapsearch sends the next request to slapd. This time the request gets handled by sssvlv_op_search() before fe_op_search() is called, because there is an active session. int overlay_op_walk( Operation *op, SlapReply *rs, slap_operation_t which, slap_overinfo *oi, slap_overinst *on){ BI_op_bind **func; int rc = SLAP_CB_CONTINUE; for (; on; on=on->on_next ) { func = &on->on_bi.bi_op_bind; if ( func[which] ) { op->o_bd->bd_info = (BackendInfo *)on; rc = func[which]( op, rs ); /* <--- sssvlv_op_search() called here */ if ( rc != SLAP_CB_CONTINUE ) break; } } if ( rc == SLAP_CB_BYPASS ) rc = SLAP_CB_CONTINUE; func = &oi->oi_orig->bi_op_bind; if ( func[which] && rc == SLAP_CB_CONTINUE ) { op->o_bd->bd_info = oi->oi_orig; rc = func[which]( op, rs ); /* <--- fe_op_search() called here */ } Chris

1 0

(ITS#6976) Build OpenLDAP on Solaris : error : could not locate usable POSIX Threads
by chathuraka.senaratne＠gmail.com 20 Jun '11

20 Jun '11

Full_Name: Samarasooriyage Gayan Chathuraka Senaratne Version: 3 OS: Solaris 64bit URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (202.69.193.78) When I try to configure OpenLDAP on Solaris I get the following error messages. I think I've set the library path environment variable to include the location of libpthread. configure: WARNING: pthread.h: present but cannot be compiled configure: WARNING: pthread.h: check for missing prerequisite headers? configure: WARNING: pthread.h: see the Autoconf documentation configure: WARNING: pthread.h: section "Present But Cannot Be Compiled" configure: WARNING: pthread.h: proceeding with the preprocessor's result configure: WARNING: pthread.h: in the future, the compiler will take precedence configure: WARNING: ## --------------------------------------------- ## configure: WARNING: ## Report this to <http://www.openldap.org/its/> ## configure: WARNING: ## --------------------------------------------- ## checking for pthread.h... yes checking POSIX thread version... 6 checking for LinuxThreads pthread.h... no checking for GNU Pth pthread.h... no checking sched.h usability... yes checking sched.h presence... yes checking for sched.h... yes checking for pthread_create in default libraries... no checking for pthread link with -kthread... no checking for pthread link with -pthread... no checking for pthread link with -pthreads... no checking for pthread link with -mthreads... no checking for pthread link with -thread... no checking for pthread link with -lpthread -lmach -lexc -lc_r... no checking for pthread link with -lpthread -lmach -lexc... no checking for pthread link with -lpthread -Wl,-woff,85... no checking for pthread link with -lpthread... no checking for pthread link with -lc_r... no checking for pthread link with -threads... no checking for pthread link with -lpthreads -lmach -lexc -lc_r... no checking for pthread link with -lpthreads -lmach -lexc... no checking for pthread link with -lpthreads -lexc... no checking for pthread link with -lpthreads... no configure: error: could not locate usable POSIX Threads Please help to solve this. Thanks Gayan

1 0

Re: (ITS#6973) Problem with sssvlv overlay and ldapsearch
by hyc＠symas.com 20 Jun '11

20 Jun '11

ctcard(a)hotmail.com wrote: > --_bbdbd3bd-a986-4f81-a676-3a9863fcc4f3_ > Content-Type: text/plain; charset="iso-8859-1" > Content-Transfer-Encoding: quoted-printable Don't send HTML emails to the ITS. I'm unable to reproduce the error you're talking about. Please provide a config that demonstrates the error, and the complete ldapsearch command invocation. Your patch cannot be correct since limits_check() is already called by the frontend at the beginning of every search operation. >> Date: Fri=2C 17 Jun 2011 09:33:22 -0700 >> From: quanah(a)zimbra.com >> To: ctcard(a)hotmail.com=3B openldap-its(a)openldap.org >> Subject: RE: (ITS#6973) Problem with sssvlv overlay and ldapsearch >> =20 >> --On Friday=2C June 17=2C 2011 8:23 AM +0000 ctcard(a)hotmail.com wrote: >> =20 >>> >>> >>>> --On Thursday=2C June 16=2C 2011 5:14 PM +0000 ctcard(a)hotmail.com wrot= > e: >>>> >>>>> >>>>> openldap 2.4.25 is better=2C but still has the LDAP_SIZELIMIT_EXCEED= > ED >>>>> bug.A possible fix is to add a call to limits_check() >>>> >>>> >>>> Please read<http://www.openldap.org/devel/contributing.html> >>>> >>>> Particularly: >>>> >>>> <http://www.openldap.org/devel/contributing.html#patches> >>> Ok=2C patch uploaded to ftp.openldap.org >>> Chris =09 >> =20 >> And the FTP URL for the patch? >> =20 > I uploaded it to the incoming directory on ftp.openldap.org with the name (= > from memory) chris-card-110617.sssvlv.c.patch as per the instructions. > > 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

(ITS#6975) Patch - Mozilla NSS - should allow cacertdir in most cases
by rmeggins＠redhat.com 20 Jun '11

20 Jun '11

Full_Name: Rich Megginson Version: 2.4.25 (current CVS HEAD) OS: RHEL6 URL: ftp://ftp.openldap.org/incoming/Mozilla-NSS-should-allow-cacertdir-in-most-… Submission from: (NULL) (76.113.106.30) openldap built with openssl allows most any value of cacertdir - directory is a file, directory does not contain any CA certs, directory does not exist - users expect if they specify TLS_REQCERT=never, no matter what the TLS_CACERTDIR setting is, TLS/SSL will just work. On the other hand, TLS_CACERT failures are hard failures - if TLS_CACERT is specified and is not a valid file, TLS/SSL will fail. These patch files are derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Red Hat. Red Hat has not assigned rights and/or interest in this work to any party. I, Rich Megginson am authorized by Red Hat, my employer, to release this work under the following terms. Red Hat hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.

1 0

Re: (ITS#6734) Implment delta-sync based MMR
by hyc＠symas.com 20 Jun '11

20 Jun '11

quanah(a)OpenLDAP.org wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.23 > OS: NA > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.45.108) > > > To help resolve ITS#6097, it would be helpful to have delta-sync MMR available. > I'm mainly filing this bug for tracking. Experimental support is now in master. A test script is provided but it probably needs to be extended. -- -- 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#6947) ldapadd crashes with LDIFs with invalid line termination
by jvcelak＠redhat.com 20 Jun '11

20 Jun '11

Hello, I have uploaded an updated version of the patch: ftp://ftp.openldap.org/incoming/jvcelak-20110620-ldif-newline-end.patch I found it better to fix the problem in ldif_read_record(), where a similar situation with EOF was already handled. If the line is not terminated by a newline character, it is added. (The previous patch fixed the bug in ldif_countlines() which looks like a blind shot now.) Jan

1 0

RE: (ITS#6973) Problem with sssvlv overlay and ldapsearch
by ctcard＠hotmail.com 17 Jun '11

17 Jun '11

--_bbdbd3bd-a986-4f81-a676-3a9863fcc4f3_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > Date: Fri=2C 17 Jun 2011 09:33:22 -0700 > From: quanah(a)zimbra.com > To: ctcard(a)hotmail.com=3B openldap-its(a)openldap.org > Subject: RE: (ITS#6973) Problem with sssvlv overlay and ldapsearch >=20 > --On Friday=2C June 17=2C 2011 8:23 AM +0000 ctcard(a)hotmail.com wrote: >=20 > > > > > >> --On Thursday=2C June 16=2C 2011 5:14 PM +0000 ctcard(a)hotmail.com wrot= e: > >> > >> > > >> > openldap 2.4.25 is better=2C but still has the LDAP_SIZELIMIT_EXCEED= ED > >> > bug.A possible fix is to add a call to limits_check() > >> > >> > >> Please read <http://www.openldap.org/devel/contributing.html> > >> > >> Particularly: > >> > >> <http://www.openldap.org/devel/contributing.html#patches> > > Ok=2C patch uploaded to ftp.openldap.org > > Chris =09 >=20 > And the FTP URL for the patch? >=20 I uploaded it to the incoming directory on ftp.openldap.org with the name (= from memory) chris-card-110617.sssvlv.c.patch as per the instructions. Chris = --_bbdbd3bd-a986-4f81-a676-3a9863fcc4f3_ 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'> <div>&gt=3B Date: Fri=2C 17 Jun 2011 09:33:22 -0700 &gt=3B From:= quanah(a)zimbra.com &gt=3B To: ctcard(a)hotmail.com=3B openldap-its@openlda= p.org &gt=3B Subject: RE: (ITS#6973) Problem with sssvlv overlay and lda= psearch &gt=3B &gt=3B --On Friday=2C June 17=2C 2011 8:23 AM +0000 c= tcard(a)hotmail.com wrote: &gt=3B &gt=3B &gt=3B &gt=3B &gt=3B &g= t=3B &gt=3B&gt=3B --On Thursday=2C June 16=2C 2011 5:14 PM +0000 ctcard@hot= mail.com wrote: &gt=3B &gt=3B&gt=3B &gt=3B &gt=3B&gt=3B &gt=3B &gt= =3B &gt=3B&gt=3B &gt=3B openldap 2.4.25 is better=2C but still has the LDAP= _SIZELIMIT_EXCEEDED &gt=3B &gt=3B&gt=3B &gt=3B bug.A possible fix is to = add a call to limits_check() &gt=3B &gt=3B&gt=3B &gt=3B &gt=3B&gt=3B<= br>&gt=3B &gt=3B&gt=3B Please read &lt=3Bhttp://www.openldap.org/devel/cont= ributing.html&gt=3B &gt=3B &gt=3B&gt=3B &gt=3B &gt=3B&gt=3B Particula= rly: &gt=3B &gt=3B&gt=3B &gt=3B &gt=3B&gt=3B &lt=3Bhttp://www.openlda= p.org/devel/contributing.html#patches&gt=3B &gt=3B &gt=3B Ok=2C patch up= loaded to ftp.openldap.org &gt=3B &gt=3B Chris &gt=3B &= gt=3B And the FTP URL for the patch? &gt=3B I uploaded it to the inc= oming directory on ftp.openldap.org with the name (from memory) chris-card-= 110617.sssvlv.c.patch as per the instructions. Chris </div> = </div></body> </html>= --_bbdbd3bd-a986-4f81-a676-3a9863fcc4f3_--

1 0

RE: (ITS#6973) Problem with sssvlv overlay and ldapsearch
by quanah＠zimbra.com 17 Jun '11

17 Jun '11

--On Friday, June 17, 2011 8:23 AM +0000 ctcard(a)hotmail.com wrote: > > >> --On Thursday, June 16, 2011 5:14 PM +0000 ctcard(a)hotmail.com wrote: >> >> > >> > openldap 2.4.25 is better, but still has the LDAP_SIZELIMIT_EXCEEDED >> > bug.A possible fix is to add a call to limits_check() >> >> >> Please read <http://www.openldap.org/devel/contributing.html> >> >> Particularly: >> >> <http://www.openldap.org/devel/contributing.html#patches> > Ok, patch uploaded to ftp.openldap.org > Chris And the FTP URL for the patch? --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

RE: (ITS#6973) Problem with sssvlv overlay and ldapsearch
by ctcard＠hotmail.com 17 Jun '11

17 Jun '11

> --On Thursday, June 16, 2011 5:14 PM +0000 ctcard(a)hotmail.com wrote: > > > > > openldap 2.4.25 is better, but still has the LDAP_SIZELIMIT_EXCEEDED > > bug.A possible fix is to add a call to limits_check() > > > Please read <http://www.openldap.org/devel/contributing.html> > > Particularly: > > <http://www.openldap.org/devel/contributing.html#patches> Ok, patch uploaded to ftp.openldap.org Chris

1 0

RE: (ITS#6973) Problem with sssvlv overlay and ldapsearch
by quanah＠zimbra.com 16 Jun '11

16 Jun '11

--On Thursday, June 16, 2011 5:14 PM +0000 ctcard(a)hotmail.com wrote: > > openldap 2.4.25 is better, but still has the LDAP_SIZELIMIT_EXCEEDED > bug.A possible fix is to add a call to limits_check() Please read <http://www.openldap.org/devel/contributing.html> Particularly: <http://www.openldap.org/devel/contributing.html#patches> Submission Formats Submissions should be submitted as a patch suitable for integration into the OpenLDAP Git source repository using git-am(1). Specifically, you should use git-format-patch(1) to construct the patch. Please review patches before submission to ensure only required changes to intended files are included in the patch AND all the intended changes are included in the patch. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

RE: (ITS#6973) Problem with sssvlv overlay and ldapsearch
by ctcard＠hotmail.com 16 Jun '11

16 Jun '11

openldap 2.4.25 is better, but still has the LDAP_SIZELIMIT_EXCEEDED bug.A possible fix is to add a call to limits_check() in sssvlv_op_search() (sssvlv.c) : --- sssvlv.c 2011-03-24 02:04:28.000000000 +0000+++ sssvlv.c.new 2011-06-16 18:07:36.000000000 +0100@@ -839,6 +839,7 @@ sess_id = find_session_by_context( si->svi_max_percon, op->o_conn->c_conn_idx, vc ? vc->vc_context : NO_VC_CONTEXT, ps ? ps->ps_cookie : NO_PS_COOKIE ); if ( sess_id >= 0 ) { so = sort_conns[op->o_conn->c_conn_idx][sess_id];+ limits_check( op, rs ); /* Is it a continuation of a VLV search? */ if ( !vc || so->so_vlv <= SLAP_CONTROL_IGNORED || vc->vc_context != so->so_vcontext ) {

1 0

Re: (ITS#6878) ppcache segfault with tavl_delete
by tjgates＠castlebranch.com 16 Jun '11

16 Jun '11

This is a multi-part message in MIME format. --------------050208080705010102070004 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I can't get this to crash under valgrind, just like it wont crash when run in debug mode. There were a few nasty messages however so I've attached the output from it thus far. -- Tyler Gates Systems Administrator Castle Branch Inc. 910-815-3880 ext 7230 tjgates(a)castlebranch.com This e-mail message, including any attachments, may contain private, confidential, and privileged information for the restricted use of the intended recipient(s). If you are not the intended recipient(s), you may NOT use, disclose, copy, or disseminate this information. Please notify the sender by return e-mail of this misdirected correspondence and destroy all copies of the original message including all attachments. Your cooperation is appreciated. --------------050208080705010102070004 Content-Type: text/plain; name="slapd.valgrind.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="slapd.valgrind.txt" ==25268== Memcheck, a memory error detector ==25268== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al. ==25268== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h for copyright info ==25268== Command: /usr/sbin/slapd -h ldap:///\ ldapi:///\ ldaps:/// -g openldap -u openldap -F /etc/ldap/slapd.d ==25268== Parent PID: 25106 ==25268== ==25268== ==25268== HEAP SUMMARY: ==25268== in use at exit: 682,293 bytes in 14,370 blocks ==25268== total heap usage: 47,421 allocs, 33,051 frees, 8,849,431 bytes allocated ==25268== ==25268== LEAK SUMMARY: ==25268== definitely lost: 199 bytes in 6 blocks ==25268== indirectly lost: 13,619 bytes in 450 blocks ==25268== possibly lost: 32,944 bytes in 10 blocks ==25268== still reachable: 635,531 bytes in 13,904 blocks ==25268== suppressed: 0 bytes in 0 blocks ==25268== Rerun with --leak-check=full to see details of leaked memory ==25268== ==25268== For counts of detected and suppressed errors, rerun with: -v ==25268== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 134 from 14) ==25273== Thread 4: ==25273== Conditional jump or move depends on uninitialised value(s) ==25273== at 0x49A249F: ??? (in /usr/lib/libdb-4.8.so) ==25273== by 0x49A3310: __log_put (in /usr/lib/libdb-4.8.so) ==25273== by 0x494E6F7: __db_addrem_log (in /usr/lib/libdb-4.8.so) ==25273== by 0x495CEB6: __db_pitem (in /usr/lib/libdb-4.8.so) ==25273== by 0x48AEAB3: ??? (in /usr/lib/libdb-4.8.so) ==25273== by 0x48B0447: __bam_iitem (in /usr/lib/libdb-4.8.so) ==25273== by 0x48A9889: ??? (in /usr/lib/libdb-4.8.so) ==25273== by 0x4955D0D: __dbc_iput (in /usr/lib/libdb-4.8.so) ==25273== by 0x495817C: __dbc_put (in /usr/lib/libdb-4.8.so) ==25273== by 0x495EBE7: __dbc_put_pp (in /usr/lib/libdb-4.8.so) ==25273== by 0x5493825: hdb_idl_insert_key (idl.c:876) ==25273== by 0x548A5E8: hdb_key_change (key.c:93) ==25273== ==25273== Syscall param pwrite64(buf) points to uninitialised byte(s) ==25273== at 0x4C1AC0B: pwrite64 (pwrite64.c:54) ==25273== by 0x49B9AB7: __os_io (in /usr/lib/libdb-4.8.so) ==25273== by 0x49A11DA: ??? (in /usr/lib/libdb-4.8.so) ==25273== by 0x49A1E7E: __log_flush_int (in /usr/lib/libdb-4.8.so) ==25273== by 0x49A376C: __log_put (in /usr/lib/libdb-4.8.so) ==25273== by 0x49C8AEA: __txn_regop_log (in /usr/lib/libdb-4.8.so) ==25273== by 0x49C5784: __txn_commit (in /usr/lib/libdb-4.8.so) ==25273== by 0x49C5850: ??? (in /usr/lib/libdb-4.8.so) ==25273== by 0x54820B7: hdb_modify (modify.c:670) ==25273== by 0x54B0257: merge_entry (pcache.c:874) ==25273== by 0x54B7FFB: cache_entries (pcache.c:2291) ==25273== by 0x54B83EC: pcache_op_cleanup (pcache.c:2396) ==25273== Address 0x6e254b4 is not stack'd, malloc'd or (recently) free'd ==25273== ==25273== Thread 3: ==25273== Conditional jump or move depends on uninitialised value(s) ==25273== at 0x49A249F: ??? (in /usr/lib/libdb-4.8.so) ==25273== by 0x49A3310: __log_put (in /usr/lib/libdb-4.8.so) ==25273== by 0x494E6F7: __db_addrem_log (in /usr/lib/libdb-4.8.so) ==25273== by 0x495CBE0: __db_ditem (in /usr/lib/libdb-4.8.so) ==25273== by 0x48AB7EE: __bam_ditem (in /usr/lib/libdb-4.8.so) ==25273== by 0x48AA39D: ??? (in /usr/lib/libdb-4.8.so) ==25273== by 0x48AACFD: ??? (in /usr/lib/libdb-4.8.so) ==25273== by 0x49546C6: __dbc_close (in /usr/lib/libdb-4.8.so) ==25273== by 0x495FC62: __dbc_close_pp (in /usr/lib/libdb-4.8.so) ==25273== by 0x5492ED7: hdb_idl_delete_key (idl.c:1034) ==25273== by 0x548A533: hdb_key_change (key.c:97) ==25273== by 0x5489AD4: indexer (index.c:214) ==25273== ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Thread 4: ==25273== Invalid read of size 4 ==25273== at 0x486C562: ??? (in /usr/lib/libldap_r-2.4.so.2.7.0) ==25273== by 0x486AEBE: ??? (in /usr/lib/libldap_r-2.4.so.2.7.0) ==25273== by 0x486B1BE: ldap_int_tls_start (in /usr/lib/libldap_r-2.4.so.2.7.0) ==25273== by 0x483ECB7: ldap_int_open_connection (in /usr/lib/libldap_r-2.4.so.2.7.0) ==25273== by 0x48570A5: ldap_new_connection (in /usr/lib/libldap_r-2.4.so.2.7.0) ==25273== by 0x483EA78: ldap_open_defconn (in /usr/lib/libldap_r-2.4.so.2.7.0) ==25273== by 0x485855F: ldap_send_initial_request (in /usr/lib/libldap_r-2.4.so.2.7.0) ==25273== by 0x484A929: ldap_sasl_bind (in /usr/lib/libldap_r-2.4.so.2.7.0) ==25273== by 0x545C877: ldap_back_dobind_int (bind.c:1482) ==25273== by 0x545D43D: ldap_back_retry (bind.c:2004) ==25273== by 0x54584A2: ldap_back_search (search.c:530) ==25273== by 0x1BAF5A: overlay_op_walk (backover.c:669) ==25273== Address 0x5ff6524 is 132 bytes inside a block of size 452 free'd ==25273== at 0x4824B3A: free (vg_replace_malloc.c:366) ==25273== by 0x4880C1F: ber_memfree_x (in /usr/lib/liblber-2.4.so.2.7.0) ==25273== by 0x484CEFE: ldap_ld_free (in /usr/lib/libldap_r-2.4.so.2.7.0) ==25273== by 0x484CFB7: ldap_unbind_ext (in /usr/lib/libldap_r-2.4.so.2.7.0) ==25273== by 0x545D3C8: ldap_back_retry (bind.c:1984) ==25273== by 0x54584A2: ldap_back_search (search.c:530) ==25273== by 0x1BAF5A: overlay_op_walk (backover.c:669) ==25273== by 0x1BBC87: over_op_func (backover.c:721) ==25273== by 0x143A83: fe_op_search (search.c:372) ==25273== by 0x144416: do_search (search.c:217) ==25273== by 0x1408C3: connection_operation (connection.c:1113) ==25273== by 0x1413C1: connection_read_thread (connection.c:1249) ==25273== ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Thread 3: ==25273== Conditional jump or move depends on uninitialised value(s) ==25273== at 0x486C56A: ??? (in /usr/lib/libldap_r-2.4.so.2.7.0) ==25273== by 0x486AEBE: ??? (in /usr/lib/libldap_r-2.4.so.2.7.0) ==25273== by 0x486B1BE: ldap_int_tls_start (in /usr/lib/libldap_r-2.4.so.2.7.0) ==25273== by 0x483ECB7: ldap_int_open_connection (in /usr/lib/libldap_r-2.4.so.2.7.0) ==25273== by 0x48570A5: ldap_new_connection (in /usr/lib/libldap_r-2.4.so.2.7.0) ==25273== by 0x483EA78: ldap_open_defconn (in /usr/lib/libldap_r-2.4.so.2.7.0) ==25273== by 0x485855F: ldap_send_initial_request (in /usr/lib/libldap_r-2.4.so.2.7.0) ==25273== by 0x484A929: ldap_sasl_bind (in /usr/lib/libldap_r-2.4.so.2.7.0) ==25273== by 0x545C877: ldap_back_dobind_int (bind.c:1482) ==25273== by 0x545D43D: ldap_back_retry (bind.c:2004) ==25273== by 0x54584A2: ldap_back_search (search.c:530) ==25273== by 0x1BAF5A: overlay_op_walk (backover.c:669) ==25273== ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() ==25273== Warning: invalid file descriptor -1 in syscall write() --------------050208080705010102070004--

1 0

Re: (ITS#6974) Possible segfault in back-monitor
by ondrej.kuznik＠acision.com 16 Jun '11

16 Jun '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/16/2011 11:23 AM, openldap-its(a)OpenLDAP.org wrote: > *** THIS IS AN AUTOMATICALLY GENERATED REPLY *** Also, in the same file, there are superfluous asserts (assert for a non-null pointer after dereferencing that same pointer) at lines 1233 and 1370. They might be considered documentation, though. - -- Ondrej Kuznik -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk35zF0ACgkQ9GWxeeH+cXsIpACglIHvpX9HCWeNL9k6/d7fn9DJ 3I8AnAuxriR7HbUTjRGFXw/qo49tEZPV =Jb1D -----END PGP SIGNATURE----- This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.

1 0

(ITS#6974) Possible segfault in back-monitor
by ondrej.kuznik＠acision.com 16 Jun '11

16 Jun '11

Full_Name: Ondrej Kuznik Version: master OS: Linux URL: ftp://ftp.openldap.org/incoming/ondrej-kuznik-20110616.patch Submission from: (NULL) (62.168.56.1) There is a minute chance of crashing OpenLDAP when registering a monitor callback while the monitor is dormant. See URL for a suggested patch. The attached file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Acision. Acision has not assigned rights and/or interest in this work to any party. I, Ondrej Kuznik am authorized by Acision, my employer, to release this work under the following terms. The attached modifications to OpenLDAP Software are subject to the following notice: Copyright 2010 Acision Redistribution and use in source and binary forms, with or without modification, are permitted only as authorized by the OpenLDAP Public License.

1 0

Re: (ITS#6892) Segfault in Syncprov overlay
by ghola＠rebelbase.com 15 Jun '11

15 Jun '11

I'm unable to reproduce this problem with the latest syncrepl.c from git.

1 0

Re: (ITS#6973) Problem with sssvlv overlay and ldapsearch
by ctcard＠hotmail.com 15 Jun '11

15 Jun '11

--_41ab47cd-3d88-4bfe-b11d-afb7d8b14738_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable sorry=2C I mistyped my email address=2C it should be ctcard(a)hotmail.com = = --_41ab47cd-3d88-4bfe-b11d-afb7d8b14738_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <html> <head> <style></style> </head> <body class=3D'hmmessage'> sorry=2C I mistyped my email address=2C it should be ctcard(a)hotmail.com = </body> </html>= --_41ab47cd-3d88-4bfe-b11d-afb7d8b14738_--

1 0

Fwd: Re: (ITS#6968) Glue objectclass created during Grouper provisioning
by hyc＠symas.com 15 Jun '11

15 Jun '11

User error, closing. -------- Original Message -------- Subject: Re: (ITS#6968) Glue objectclass created during Grouper provisioning Date: Wed, 15 Jun 2011 10:40:32 +0100 From: Mark Cairney <Mark.Cairney(a)ed.ac.uk> To: Howard Chu <hyc(a)symas.com> Hi, > > Then please strip out those attributes and objectclasses and verify that the LDIF file still reproduces the problem. I can't do this at the moment as this system will be going live imminently however I think I've tracked down the root cause of the problem. One of our servers was going to Redhat for it's NTP sync rather than the same local source as the others so it's clock was slightly skewed in relation. The issue now seems to no longer be occuring having thrown some fairly large LDIFs as the server as a test. >> > Just clicking on the link in any web browser. Also using the link with wget. Either way authentication is requested. >> I've moved the zip if you still want to take a look but given the cause I'm happy for the issue to be closed. IMO it was probably premature raising it as a bug but I was advised to on the list! I'll reply to my post on the list with the cause/solution for completeness. Kind regards, Mark -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

1 0

(ITS#6973) Problem with sssvlv overlay and ldapsearch
by ctcard＠hotmal.com 14 Jun '11

14 Jun '11

Full_Name: Chris Card Version: 2.4.23 OS: Centos 5.4 URL: Submission from: (NULL) (91.194.158.133) I am running slapd with a bdb back end, and using ldapsearch to query it. My ldapsearch command looks like this: ldapsearch -h localhost -x -b "..........." -D ".........." -w .... -E \!sss=mail:caseIgnoreIA5Match -E \!vlv=0/10/0/10 which returns the first 11 records and then prompts: # search result search: 2 result: 0 Success control: 1.2.840.113556.1.4.474 false MAMKAQA= sortResult: (0) Success control: 2.16.840.1.113730.3.4.10 false MA8CAQACATkCAQAEBOhhowg= vlvResult: pos=0 count=57 context=6GGjCA== (0) Success # numResponses: 12 # numEntries: 11 Press [before/after(/offset/count|:value)] Enter for the next window. Then, when I press Enter ldapsearch outputs the following and exits: # extended LDIF # # LDAPv3 # base <......> with scope subtree # filter: (objectclass=*) # requesting: ALL # with server side sorting critical control # with virtual list view critical control: 0/10/10/57 # # search result search: 3 result: 4 Size limit exceeded # numResponses: 1 If I then try the search again ldapsearch outputs: # extended LDIF # # LDAPv3 # base <......> with scope subtree # filter: (objectclass=*) # requesting: ALL # with server side sorting critical control # with virtual list view critical control: 0/10/0/10 # # search result search: 2 result: 51 Server is busy text: Other sort requests already in progress # numResponses: 1 The "Size limit exceeded" error appears to come from slap_send_search_entry() in result.c: if ( op->ors_slimit >= 0 && rs->sr_nentries >= op->ors_slimit ) { return LDAP_SIZELIMIT_EXCEEDED; } because op->ors_slimit is 0 instead of SLAP_NO_LIMIT (-1). If I do the ldapsearch with an explicit size limit, using the -z flag, e.g. ldapsearch -h localhost -x -b "..........." -D ".........." -w .... -E \!sss=mail:caseIgnoreIA5Match -E \!vlv=0/10/0/10 -z 20 then I don't get the "Size limit exceeded" error, and all the records are output by ldapsearch with a prompt after each set of 11 records, but after all the records have been output there is a different error before ldapsearch exits: # extended LDIF # # LDAPv3 # base <dc=blackspider,dc=com> with scope subtree # filter: (objectclass=*) # requesting: ALL # with server side sorting critical control # with virtual list view critical control: 0/10/60/57 # # search result search: 8 result: 76 Virtual List View error control: 2.16.840.1.113730.3.4.10 false MA8CATICATkCAU0EBHBFIQo= vlvResult: pos=50 count=57 context=cEUhCg== (77) Unknown error # numResponses: 1 and again a subsequent ldapsearch request gets the "Server is busy" error.

1 0

Re: (ITS#6657) back-sql segfault in backsql_search
by hyc＠symas.com 14 Jun '11

14 Jun '11

Timo Teräs wrote: > On 06/14/2011 08:24 AM, hyc(a)symas.com wrote: >> On Tue, Jun 14, 2011 at 08:16:18AM +0300, Timo Ter?s wrote: >>> On 06/13/2011 11:56 PM, Howard Chu wrote: >>>> timo.teras(a)iki.fi wrote: >>>>> ITS#6691 seems to be same issue. >>>>> >>>>> I have a patch to fix this. >>>>> >>>>> It's available at: >>>>> http://git.alpinelinux.org/cgit/aports.git/plain/main/openldap/openldap-bac… >>>>> >>>> Thanks for the patch, now in git master. >>> >>> Good. Though, it would have been polite to credit me as the commit author. >> >> You were credited in the release branch. > > Oh, right. > >> In the future use git format-patch and things like this won't get overlooked. > > I did not have the git tree available on the 64-bit machine I was given > to work with. And at that point I did not even know which version > control you used. You are expected to have read this already before submitting code: http://www.openldap.org/devel/contributing.html -- -- 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#6657) back-sql segfault in backsql_search
by timo.teras＠iki.fi 13 Jun '11

13 Jun '11

On 06/14/2011 08:24 AM, hyc(a)symas.com wrote: > On Tue, Jun 14, 2011 at 08:16:18AM +0300, Timo Ter?s wrote: >> On 06/13/2011 11:56 PM, Howard Chu wrote: >>> timo.teras(a)iki.fi wrote: >>>> ITS#6691 seems to be same issue. >>>> >>>> I have a patch to fix this. >>>> >>>> It's available at: >>>> http://git.alpinelinux.org/cgit/aports.git/plain/main/openldap/openldap-bac… >>>> >>> Thanks for the patch, now in git master. >> >> Good. Though, it would have been polite to credit me as the commit author. > > You were credited in the release branch. Oh, right. > In the future use git format-patch and things like this won't get overlooked. I did not have the git tree available on the 64-bit machine I was given to work with. And at that point I did not even know which version control you used. git commit does have --author="" switch, so it's very easy to set the patch author properly even if it's not in git patch format.

1 0

Re: (ITS#6657) back-sql segfault in backsql_search
by hyc＠symas.com 13 Jun '11

13 Jun '11

On Tue, Jun 14, 2011 at 08:16:18AM +0300, Timo Ter?s wrote: > On 06/13/2011 11:56 PM, Howard Chu wrote: > > timo.teras(a)iki.fi wrote: > >> ITS#6691 seems to be same issue. > >> > >> I have a patch to fix this. > >> > >> It's available at: > >> http://git.alpinelinux.org/cgit/aports.git/plain/main/openldap/openldap-bac… > >> > > Thanks for the patch, now in git master. > > Good. Though, it would have been polite to credit me as the commit author. You were credited in the release branch. In the future use git format-patch and things like this won't get overlooked. > > Thanks, > Timo

1 0

RE: (ITS#6964) ./configure bug when specifying openssl as the TLS library to use
by the_uhu＠hotmail.com 13 Jun '11

13 Jun '11

--_d1f53d59-c756-486d-94a1-c6fa39a61c52_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi=2C Am wondering what I am missing here? Because to get OpenLDAP to compile wit= h openssl as the TLS library to use=2C I had change this line. You said that line 19408 on your copy of configure is not the LIBS line bel= ow even though I downloaded openldap fresh - could you offer an explanation= please? Paul. From: the_uhu(a)hotmail.com To: openldap-its(a)openldap.org Subject: RE: (ITS#6964) ./configure bug when specifying openssl as the TLS = library to use Date: Thu=2C 9 Jun 2011 00:16:10 +0000 I've just downloaded openldap stable fresh=2C opened up configure and this = is at line 19408 without an if check: LIBS=3D"-lssl -lcrypto -lRSAglue -lrsaref $LIBS" Also checked the source repository on the website and it's there also. Can you please double check? Paul. > Date: Wed=2C 8 Jun 2011 22:13:55 +0000 > From: openldap-its(a)OpenLDAP.org > To: the_uhu(a)hotmail.com > Subject: Re: (ITS#6964) ./configure bug when specifying openssl as the TL= S library to use >=20 > I don't know where your configure script came from=2C but there's nothing= related > to OpenSSL at line 19408 of the current released configure script=2C and = our > script has had logic to detect -lrsaref since 1999. >=20 > Closing this ITS. Use the actual configure script supplied by the OpenLDA= P > Project. = --_d1f53d59-c756-486d-94a1-c6fa39a61c52_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <html> <head> <style></style> </head> <body class=3D'hmmessage'> Hi=2C Am wondering what I am missing here? Because to get OpenLDAP t= o compile with openssl as the TLS library to use=2C I had change this line.= You said that line 19408 on your copy of configure is not the LIBS = line below even though I downloaded openldap fresh - could you offer an exp= lanation please? Paul. <hr id=3D"stopSpelling">From: the_uhu@= hotmail.com To: openldap-its(a)openldap.org Subject: RE: (ITS#6964) ./c= onfigure bug when specifying openssl as the TLS library to use Date: Thu= =2C 9 Jun 2011 00:16:10 +0000 <meta http-equiv=3D"Content-Type" content=3D"text/html=3B charset=3Dunicode= "> <meta name=3D"Generator" content=3D"Microsoft SafeHTML"> <style> .ExternalClass .ecxhmmessage P {padding:0px=3B} .ExternalClass body.ecxhmmessage {font-size:10pt=3Bfont-family:Tahoma=3B} </style> I've just downloaded openldap stable fresh=2C opened up configure and this = is at line 19408 without an if check: LIBS=3D"-lssl -lcrypto -lRSAgl= ue -lrsaref $LIBS" Also checked the source repository on the website= and it's there also. Can you please double check? Paul. <= br> &gt=3B Date: Wed=2C 8 Jun 2011 22:13:55 +0000 &gt=3B From: openld= ap-its(a)OpenLDAP.org &gt=3B To: the_uhu(a)hotmail.com &gt=3B Subject: Re= : (ITS#6964) ./configure bug when specifying openssl as the TLS library to = use &gt=3B &gt=3B I don't know where your configure script came from= =2C but there's nothing related &gt=3B to OpenSSL at line 19408 of the c= urrent released configure script=2C and our &gt=3B script has had logic = to detect -lrsaref since 1999. &gt=3B &gt=3B Closing this ITS. Use t= he actual configure script supplied by the OpenLDAP &gt=3B Project. = </body> </html>= --_d1f53d59-c756-486d-94a1-c6fa39a61c52_--

1 0

Re: (ITS#6657) back-sql segfault in backsql_search
by hyc＠symas.com 13 Jun '11

13 Jun '11

timo.teras(a)iki.fi wrote: > ITS#6691 seems to be same issue. > > I have a patch to fix this. > > It's available at: > http://git.alpinelinux.org/cgit/aports.git/plain/main/openldap/openldap-bac… > > - Timo > > > Thanks for the patch, now 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#6971) Incorrect configure option in documentation
by quanah＠zimbra.com 13 Jun '11

13 Jun '11

--On Sunday, June 12, 2011 4:15 AM +0000 crhea(a)mayo.edu wrote: > Full_Name: Cris Rhea > Version: 2.4.25 > OS: Linux/CentOS > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (129.176.151.29) > > > http://www.openldap.org/doc/admin24/install.html#TCP%20Wrappers > > Sections 4.2.6 and 4.3 mention using "--with-wrappers" to enable TCP > Wrappers. This > option does not cause "configure" to fail, but instead, silently does > nothing. > > The correct option is "--enable-wrappers". > > This is also a minor security bug as people might think their systems have > TCP Wrapper restrictions, but unless someone tests it, they won't realize > it isn't working. > Thanks for the report, this has been fixed in the git master. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6972) [PATCH] Autogroup double-free of LDAPURLDesc *lud in autogroup_add_group when the URL contains a filter with >1 attribute.
by gerry＠everythingsucks.co.uk 13 Jun '11

13 Jun '11

--001485f86174bced0304a59d35e3 Content-Type: text/plain; charset=ISO-8859-1 In further testing this patch requires modification, I'll follow up shortly with a fixed up version. G --001485f86174bced0304a59d35e3 Content-Type: text/html; charset=ISO-8859-1 In further testing this patch requires modification, I'll follow up shortly with a fixed up version. G --001485f86174bced0304a59d35e3--

1 0

Re: (ITS#6970) OpenLDAP 2.4.25 MemberOf + AutoGroup user has stale "memberof" attributes for target group after removal from trigger group
by gerry＠everythingsucks.co.uk 13 Jun '11

13 Jun '11

--00163628477eca7fed04a59d338b Content-Type: text/plain; charset=ISO-8859-1 In further testing in our environment we've found this patch to be ineffective. We're seeing lockups consistently when changing other attributes. I'll follow up with more details and some traces shortly (miight try with tip first though :0) G --00163628477eca7fed04a59d338b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable In further testing in our environment we've found this patch to be inef= fective. We're seeing lockups consistently when changing other a= ttributes. I'll follow up with more details and some traces shor= tly (miight try with tip first though :0) G --00163628477eca7fed04a59d338b--

1 0

Re: (ITS#6691) error 4 in slapd: segfault with back-sql in debian amd64
by timo.teras＠iki.fi 13 Jun '11

13 Jun '11

ITS#6657 seems to be same issue. I have a patch to fix this. It's available at: http://git.alpinelinux.org/cgit/aports.git/plain/main/openldap/openldap-bac… - Timo

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs