openldap-bugs

openldap-bugs@openldap.org

1 participants
20958 discussions

Re: (ITS#6103) canceled operations do not respond
by hyc＠symas.com 11 May '09

11 May '09

Hallvard B Furuseth wrote: > Howard Chu writes: >> The tooLate reply is correct; back-null doesn't ever check for >> cancel/abandon therefore the operation is *not* successfully >> canceled. Likewise, back-bdb/hdb only checks in Delete if there is a >> transaction retry. > > No difference if I use back-ldif, which does check for abandon. > >> The lack of reply from the original op - that's a simple oversight. >> send_ldap_ber() checks for op->o_abandon and returns silently if it's set. I >> guess we need to also check for o_cancel to let it proceed. > > The operation does not reach send_ldap_ber(). To verify, I temporarily > inserted assert(!op->o_abandon) just before send_ldap_ber()'s o_abandon > test. send_ldap_response() notices both o_abandon and SLAPD_ABANDON, > and skips to the cleanup code in either case. > > Also, backend operations that do return SLAPD_ABANDON - at least Search > in backglue and BDB - may do so without calling send_ldap_response() at > all. Pierangelo made partial fixes in ITS#4645. See also ITS#6059, > which I may have misunderstood somewhat. (Sorry, Rein.) > > Maybe o_abandon should only mean that: > - (a) the backend has been asked to abandon the operation, > - (b) slapd must check and react to o_cancel, > - (c) if not o_cancel, send_ldap_ber() need not send. > The test case with delete / back-ldif now works in HEAD. backglue and back-bdb should be OK now as well. -- -- 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#6099) SIGSEGV heimdal+ldap during kadmin -l init
by dewayne.geraghty＠heuristicsystems.com.au 10 May '09

10 May '09

This is a multi-part message in MIME format. ------=_NextPart_000_0015_01C9D21A.C8D0F590 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Heimdal 1.0.1 was constructed from the FreeBSD 7.2R's port handling system for contributed software. From Howard's analysis, Heimdal 1.0.1 is passing incorrect values to LDAP 2.4.16. Over to heimdal's maintainer on FreeBSD. Thank-you for your prompt analysis. ------=_NextPart_000_0015_01C9D21A.C8D0F590 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META http-equiv=3DContent-Type content=3D"text/html; = charset=3Dus-ascii"> <META content=3D"MSHTML 6.00.6000.16809" name=3DGENERATOR></HEAD> <BODY> <DIV><FONT face=3DArial size=3D2><SPAN = class=3D407062323-10052009>Heimdal 1.0.1 was=20 constructed from the FreeBSD 7.2R's port handling system for = contributed=20 software. From Howard's analysis, Heimdal 1.0.1 is=20 passing incorrect values to LDAP 2.4.16.  Over to = heimdal's=20 maintainer on FreeBSD.  Thank-you for your prompt=20 analysis. </SPAN></FONT></DIV></BODY></HTML> ------=_NextPart_000_0015_01C9D21A.C8D0F590--

1 0

Re: (ITS#6103) canceled operations do not respond
by h.b.furuseth＠usit.uio.no 10 May '09

10 May '09

Howard Chu writes: > The tooLate reply is correct; back-null doesn't ever check for > cancel/abandon therefore the operation is *not* successfully > canceled. Likewise, back-bdb/hdb only checks in Delete if there is a > transaction retry. No difference if I use back-ldif, which does check for abandon. > The lack of reply from the original op - that's a simple oversight. > send_ldap_ber() checks for op->o_abandon and returns silently if it's set. I > guess we need to also check for o_cancel to let it proceed. The operation does not reach send_ldap_ber(). To verify, I temporarily inserted assert(!op->o_abandon) just before send_ldap_ber()'s o_abandon test. send_ldap_response() notices both o_abandon and SLAPD_ABANDON, and skips to the cleanup code in either case. Also, backend operations that do return SLAPD_ABANDON - at least Search in backglue and BDB - may do so without calling send_ldap_response() at all. Pierangelo made partial fixes in ITS#4645. See also ITS#6059, which I may have misunderstood somewhat. (Sorry, Rein.) Maybe o_abandon should only mean that: - (a) the backend has been asked to abandon the operation, - (b) slapd must check and react to o_cancel, - (c) if not o_cancel, send_ldap_ber() need not send. -- Hallvard

1 0

Re: (ITS#6103) canceled operations do not respond
by hyc＠symas.com 10 May '09

10 May '09

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: HEAD > OS: Linux > URL: > Submission from: (NULL) (129.240.6.233) > Submitted by: hallvard > > > RFC 3909 says both the Cancel operation and the canceled operation > shall respond. However I'm getting tooLate reply from Cancel > and no response from the successfully cancelled operation: The tooLate reply is correct; back-null doesn't ever check for cancel/abandon therefore the operation is *not* successfully canceled. Likewise, back-bdb/hdb only checks in Delete if there is a transaction retry. The lack of reply from the original op - that's a simple oversight. send_ldap_ber() checks for op->o_abandon and returns silently if it's set. I guess we need to also check for o_cancel to let it proceed. > > slapd.conf: > include servers/slapd/schema/core.schema > database null > suffix "cn=null" > client: > DEL cn=null > sleep 0.1 sec > CANCEL<previous op> > sleep 0.2 sec > UNBIND > receives the folllowing statslog: > conn=1 fd=9 ACCEPT from IP=127.0.0.1:48774 (IP=127.0.0.1:3890) > conn=1 op=0 DEL dn="cn=null" > conn=1 op=1 EXT oid=1.3.6.1.1.8 > conn=1 op=1 CANCEL msg=1 > conn=1 op=0 ABANDONED > conn=1 op=1 RESULT oid= err=120 text= > conn=1 op=2 UNBIND > conn=1 fd=9 closed > and the client gets just ExtendedResponse tooLate before connection closes > > with the following patch to slapd: > > Index: delete.c > --- delete.c 21 Jan 2009 23:40:26 -0000 1.144 > +++ delete.c 9 May 2009 22:06:07 -0000 > @@ -75,4 +75,9 @@ > op->o_log_prefix, op->o_req_dn.bv_val, 0, 0, 0 ); > > + { > + struct timeval timeout = { 0, 200000 }; > + select(0, NULL, NULL, NULL,&timeout); > + } > + > if( op->o_req_ndn.bv_len == 0 ) { > Debug( LDAP_DEBUG_ANY, "%s do_delete: root dse!\n", > Index: result.c > --- result.c 14 Mar 2009 05:47:43 -0000 1.329 > +++ result.c 9 May 2009 22:06:07 -0000 > @@ -418,4 +418,6 @@ > if ( rs->sr_err == SLAPD_ABANDON || op->o_abandon ) { > rc = SLAPD_ABANDON; > + Statslog( LDAP_DEBUG_STATS, > + "%s ABANDONED\n", op->o_log_prefix, 0, 0, 0, 0 ); > goto clean2; > } > > > -- -- 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#6102) configure skips winsock check
by hyc＠symas.com 10 May '09

10 May '09

slapd(a)hannebauer.name wrote: > Full_Name: Christoph Hannebauer > Version: 2.4.16 > OS: Windows/cygwin > URL: www.hannebauer.name/configure.in.patch > Submission from: (NULL) (77.189.243.40) > > > I use cygwin to build OpenLDAP with the MinGW target. The configure script > incorrectly skips the check for winsock. This results in a missing -lws2_32 > parameter in some makefiles, I get error messages like > > /cygdrive/d/TestProgs/openldap-2.4.16/libraries/liblber/io.c:531: undefined > reference to `_WSASetLastError@4' > > The author of ITS#6078 (http://www.openldap.org/its/index.cgi/Incoming?id=6078) > notes that this problem occurs since 2.4.14, but I haven't tested that. Thanks. Yes, the configure script handling of winsock changed between 2.4.13 and 2.4.14. This patch is now committed to HEAD. > > The attached patch file is a diff to configure.in version 1.696. I have tested > it on my machine and it solved the problem (The reason was an erroneous > if-statement. The if-condition should only evaluate true if MS Visual C++ is > used). I've also included another small fix for the winsock detection which > happened to not affect my system, but seemed obviously wrong. It's only a very > minor fix, so I assumed it would be okay to not open another ticket for that > patch. If I am wrong, please notify me and I will split up the patch file. > > I hope it's okay to have the legal statement here, otherwise I will include it > as a comment in the patch file: > I, Christoph Hannebauer, 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. > -- -- 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#6103) canceled operations do not respond
by h.b.furuseth＠usit.uio.no 09 May '09

09 May '09

Full_Name: Hallvard B Furuseth Version: HEAD OS: Linux URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard RFC 3909 says both the Cancel operation and the canceled operation shall respond. However I'm getting tooLate reply from Cancel and no response from the successfully cancelled operation: slapd.conf: include servers/slapd/schema/core.schema database null suffix "cn=null" client: DEL cn=null sleep 0.1 sec CANCEL <previous op> sleep 0.2 sec UNBIND receives the folllowing statslog: conn=1 fd=9 ACCEPT from IP=127.0.0.1:48774 (IP=127.0.0.1:3890) conn=1 op=0 DEL dn="cn=null" conn=1 op=1 EXT oid=1.3.6.1.1.8 conn=1 op=1 CANCEL msg=1 conn=1 op=0 ABANDONED conn=1 op=1 RESULT oid= err=120 text= conn=1 op=2 UNBIND conn=1 fd=9 closed and the client gets just ExtendedResponse tooLate before connection closes with the following patch to slapd: Index: delete.c --- delete.c 21 Jan 2009 23:40:26 -0000 1.144 +++ delete.c 9 May 2009 22:06:07 -0000 @@ -75,4 +75,9 @@ op->o_log_prefix, op->o_req_dn.bv_val, 0, 0, 0 ); + { + struct timeval timeout = { 0, 200000 }; + select(0, NULL, NULL, NULL, &timeout); + } + if( op->o_req_ndn.bv_len == 0 ) { Debug( LDAP_DEBUG_ANY, "%s do_delete: root dse!\n", Index: result.c --- result.c 14 Mar 2009 05:47:43 -0000 1.329 +++ result.c 9 May 2009 22:06:07 -0000 @@ -418,4 +418,6 @@ if ( rs->sr_err == SLAPD_ABANDON || op->o_abandon ) { rc = SLAPD_ABANDON; + Statslog( LDAP_DEBUG_STATS, + "%s ABANDONED\n", op->o_log_prefix, 0, 0, 0, 0 ); goto clean2; }

1 0

(ITS#6102) configure skips winsock check
by slapd＠hannebauer.name 09 May '09

09 May '09

Full_Name: Christoph Hannebauer Version: 2.4.16 OS: Windows/cygwin URL: www.hannebauer.name/configure.in.patch Submission from: (NULL) (77.189.243.40) I use cygwin to build OpenLDAP with the MinGW target. The configure script incorrectly skips the check for winsock. This results in a missing -lws2_32 parameter in some makefiles, I get error messages like /cygdrive/d/TestProgs/openldap-2.4.16/libraries/liblber/io.c:531: undefined reference to `_WSASetLastError@4' The author of ITS#6078 (http://www.openldap.org/its/index.cgi/Incoming?id=6078) notes that this problem occurs since 2.4.14, but I haven't tested that. The attached patch file is a diff to configure.in version 1.696. I have tested it on my machine and it solved the problem (The reason was an erroneous if-statement. The if-condition should only evaluate true if MS Visual C++ is used). I've also included another small fix for the winsock detection which happened to not affect my system, but seemed obviously wrong. It's only a very minor fix, so I assumed it would be okay to not open another ticket for that patch. If I am wrong, please notify me and I will split up the patch file. I hope it's okay to have the legal statement here, otherwise I will include it as a comment in the patch file: I, Christoph Hannebauer, 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#6096) 2.4.16 replica segfault
by luca.scamoni＠sys-net.it 09 May '09

09 May '09

hyc(a)symas.com ha scritto: > > It certainly looks that way. What version is the provider, what version is the > consumer? You only said there were mixed versions before, you never specified > which was which. > Both are same version: 2.4.16 + patches (looking at RELENG I simply anticipated Quanah in merging from HEAD). Ing. Luca Scamoni Responsabile Ricerca e Sviluppo SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 0382 573859 (137) Fax: +39 0382 476497 Email: luca.scamoni(a)sys-net.it -----------------------------------

1 0

Re: (ITS#6096) 2.4.16 replica segfault
by hyc＠symas.com 09 May '09

09 May '09

masarati(a)aero.polimi.it wrote: > luca.scamoni(a)sys-net.it wrote: >> hyc(a)symas.com ha scritto: >>> Good idea. >>> >>> Also, I think the original LDAP message should still be intact, in frame 6 >>> "msg" - perhaps you can extract the DN that was actually received and figure >>> out why it had a problem. >>> >> This is the msg from frame 6 >> >> (gdb) p msg->lm_ber->ber_buf[0]@100 >> $4 = >> "\002\001\002d\202\0046\004\000\000\202\004003\004\tentryUUID\000&\004$6a0ba116-b291-11da-8006-87f6e679f1bd0*\004\vobjectClass\000\033\004\024cRLDistribution" > > The second '\000' after '\004' (octet string) was probably put by > ber_scanf("m") to terminate the string, but the first one seems to be > the length of the octet string! So apparently the message actually > contained an empty DN, which makes little sense. Could the error be at > the provider's side? It certainly looks that way. What version is the provider, what version is the consumer? You only said there were mixed versions before, you never specified which was which. -- -- 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#6099) SIGSEGV heimdal+ldap during kadmin -l init
by hyc＠symas.com 09 May '09

09 May '09

dewayne_freebsd(a)yahoo.com wrote: > Full_Name: Dewayne Geraghty > Version: 2.4.16 > OS: FreeBSD-7.2R > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (58.172.112.108) > > > Fresh build of OS, ports from heimdal, openldap-2.4.16, cyrus-sasl-2.1.22_2, > ltdl-1.5.26. What does "ports from heimdal" mean? What version of Heimdal are you using? I've built Heimdal 1.2.1 and it works fine. > During kadmin -l init --realm-max-ticket-life=unlimited > --realm-max-renewable-life=unlimited HS2 > a segmentation fault is raised. > > gdb /usr/local/sbin/kadmin > run -l init --realm-max-ticket-life=unlimited > --realm-max-renewable-life=unlimited HS2 > #0 0x285693c6 in memmove () from /lib/libc.so.7 > #1 0x28235c0d in ber_write (ber=0x2860b340, buf=0x51<Error reading address > 0x51: Bad address>, len=81, nosos=0) > at io.c:116 > #2 0x28234525 in ber_put_ostring (ber=0x2860b340, str=0x51<Error reading > address 0x51: Bad address>, len=81, > tag=4) at encode.c:357 This trace indicates that incorrect parameters were provided to the ldap_add function(s). In particular, the attrs passed in are using char * values, but the flags were set to indicate that struct bervals were being passed. As such, this is a bug in whatever version of Heimdal you used. There is no OpenLDAP issue here, this ITS will be closed. Furthermore, it appears that there is no bug in current Heimdal versions either. > #3 0x28234625 in ber_put_berval (ber=0x2860b340, bv=0x2860711c, tag=4294967295) > at encode.c:382 > #4 0x28235729 in ber_printf (ber=0x2860b340, fmt=0x281c99de "V]N}") at > encode.c:838 > #5 0x2819a074 in ldap_add_ext (ld=0x2863d100, > dn=0x28618180 "krb5PrincipalName=krbtgt/HS2@HS2,ou=Users,dc=heuristicsystems,dc=com,dc=au", > attrs=0x2860c420, > sctrls=0x0, cctrls=0x0, msgidp=0xbfbfe6bc) at add.c:170 > #6 0x2819a2b0 in ldap_add_ext_s (ld=0x2863d100, > dn=0x28618180 "krb5PrincipalName=krbtgt/HS2@HS2,ou=Users,dc=heuristicsystems,dc=com,dc=au", > attrs=0x2860c420, > sctrls=0x0, cctrls=0x0) at add.c:229 > #7 0x2819a36b in ldap_add_s (ld=0x2863d100, > dn=0x28618180 "krb5PrincipalName=krbtgt/HS2@HS2,ou=Users,dc=heuristicsystems,dc=com,dc=au", > attrs=0x2860c420) > at add.c:243 > #8 0x280b028f in LDAP_store (context=0x286010b0, db=0x2860a040, flags=0, > entry=0xbfbfe770) at hdb-ldap.c:1580 > #9 0x2809a8f0 in kadm5_s_create_principal (server_handle=0x2861a0c0, > princ=0xbfbfea1c, mask=17, > password=0xbfbfe810 "Vbc2zAiigq") at create_s.c:182 > #10 0x2808eac9 in kadm5_create_principal (server_handle=0x2861a0c0, > princ=0xbfbfea1c, mask=17, > password=0xbfbfe810 "Vbc2zAiigq") at common_glue.c:64 > and > (gdb) x 0x2860711c > 0x2860711c: 0x00000051 > > This is reproducable with/without overlays (except for smbk5pwd overlay); built > and tested afresh on two machines, using make -pipe -O0 -g3 > > Note to build smbk5passwd on FreeBSD, needed to change smbk5pwd Makefile: > #HEIMDAL_INC=-I/usr/heimdal/include > HEIMDAL_INC=-I/usr/local/include > #HEIMDAL_LIB=-L/usr/heimdal/lib -lkrb5 -lkadm5srv > HEIMDAL_LIB=-L/usr/local/lib -lkrb5 -lkadm5srv > > The ldap database is built using one group entry (ou=Users,dc=..). Have used > ldap for 3 years, kerberos for 4 months. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs