openldap-bugs May 2007

openldap-bugs@openldap.org

42 participants
156 discussions

(ITS#4957) destroying uninitialized mutexed after failed startup
by h.b.furuseth＠usit.uio.no 13 May '07

13 May '07

Full_Name: Hallvard B Furuseth Version: RE23 OS: URL: http://www.openldap.org/devel/cvsweb.cgi/servers/slapd/schema_init.c.diff?r… Submission from: (NULL) (129.240.202.105) Submitted by: hallvard If RE23 startup fails, ad_undef_mutex and oc_undef_mutex can be destroyed without having been initialized. Thus slapd can crash. Fix: schema_init.c rev 1.388. (I haven't committed to non-HEAD for ages, I don't rememer if I just commit it or if there are more formalities involved?)

1 0

Re: (ITS#4943) tpool.c pause vs. finish
by h.b.furuseth＠usit.uio.no 12 May '07

12 May '07

hyc(a)symas.com writes: > h.b.furuseth(a)usit.uio.no wrote: >> - TID_HASH() fails if several ldap_pvt_thread_t bit patterns can >> represent the same thread ID, e.g. if it is a struct/integer type with >> padding bytes/bits. >> > That doesn't matter, since the table will use linear probing to compare > thread IDs. Ah, it works when creating new threads. But not in pool_context(), which stops searching when it hits an unused slot (thread ID tid_zero). -- Regards, Hallvard

1 0

Re: (ITS#4943) tpool.c pause vs. finish
by hyc＠symas.com 12 May '07

12 May '07

h.b.furuseth(a)usit.uio.no wrote: > h.b.furuseth(a)usit.uio.no writes: >> Howard Chu writes: >>> Since there is only one thread pool in use, it is impossible for another >>> thread to be active. >> No. Though it's true that my concern above was wrong. >> >> It is "ltp_active_count--" which triggers the start of a pause. (...) > > Sorry again, I was confusing 3 problems after two long days. It's the > active (unpaused) thread which would be calling _context() of course. > > In any case, thank you for the reply. I know what to test now... > > > Another problem, which I think I'm repeating from an earlier discussion: > > - TID_HASH() fails if several ldap_pvt_thread_t bit patterns can > represent the same thread ID, e.g. if it is a struct/integer type with > padding bytes/bits. > That doesn't matter, since the table will use linear probing to compare thread IDs. -- -- Howard Chu Chief Architect, 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#4943) tpool.c pause vs. finish
by h.b.furuseth＠usit.uio.no 12 May '07

12 May '07

h.b.furuseth(a)usit.uio.no writes: >Howard Chu writes: >> Since there is only one thread pool in use, it is impossible for another >> thread to be active. > > No. Though it's true that my concern above was wrong. > > It is "ltp_active_count--" which triggers the start of a pause. (...) Sorry again, I was confusing 3 problems after two long days. It's the active (unpaused) thread which would be calling _context() of course. In any case, thank you for the reply. I know what to test now... Another problem, which I think I'm repeating from an earlier discussion: - TID_HASH() fails if several ldap_pvt_thread_t bit patterns can represent the same thread ID, e.g. if it is a struct/integer type with padding bytes/bits. It might be better to let TID_HASH cast the ID to an unsigned integer type and hash that. Then it won't compile if ldap_pvt_thread_t is a struct, so we get a warning in _some_ cases when it can break. -- Regards, Hallvard

1 0

slapd + TLS + verify client is not working as expected
by Andreas Roth 12 May '07

12 May '07

Hello, i'm using slapd 2.3.30 on a Ubuntu 7.04 AMD64 machine and i've have some trouble to get it running with TLS. When the slapd daemon is started during the system start-up i cannot connect to the LDAP server with TLS. After a long search i figured out, that the slapd daemon requests a client certificate, but i haven't configured the server to do so. Here is the TLS configuration of slapd: TLSCipherSuite HIGH:MEDIUM:+SSLv2 TLSVerifyClient never TLSCACertificateFile /etc/ldap/certs/root.crt #TLSCACertificatePath /etc/ldap/certs TLSCertificateFile /etc/ldap/certs/ldap.arsoft.homeip.net.crt TLSCertificateKeyFile /etc/ldap/private/ldap.arsoft.homeip.net.pem And here's what the server says when i connect to it using ldapsearch -x -ZZ ... TLS trace: SSL_accept:SSLv3 flush data tls_read: want=5 error=Resource temporarily unavailable TLS trace: SSL_accept:error in SSLv3 read client certificate A TLS trace: SSL_accept:error in SSLv3 read client certificate A daemon: select: listen=6 active_threads=0 tvp=zero daemon: activity on 1 descriptor daemon: activity on: 11r daemon: read activity on 11 connection_get(11) connection_get(11): got connid=187 connection_read(11): checking for input on id=187 tls_read: want=5, got=5 0000: 16 03 01 00 07 ..... tls_read: want=7, got=7 0000: 0b 00 00 03 00 00 00 ....... tls_write: want=7, written=7 0000: 15 03 01 00 02 02 28 ......( TLS trace: SSL3 alert write:fatal:handshake failure TLS trace: SSL_accept:error in SSLv3 read client certificate B TLS: can't accept. TLS: error:140890C7:SSL routines:SSL3_GET_CLIENT_CERTIFICATE:peer did not return a certificate s3_srvr.c:2455 connection_read(11): TLS accept failure error=-1 id=187, closing connection_closing: readying conn=187 sd=11 for close connection_close: conn=187 sd=11 The interesting thing is, that when i restart the slapd daemon manually, the server works fine and TLS is also working. I don't known if this porblem is really a bug or not, but i don't know how to solve this problem by myself. Any help or advise is welcomed. Thanks, A. Roth

1 0

Re: (ITS#4943) tpool.c pause vs. finish
by h.b.furuseth＠usit.uio.no 11 May '07

11 May '07

I wrote: > So if I call setkey and the key already exists and has an ltk_free > function, it's my responsibility to know the old data was there, and > free it or take back ownership? (A clarifying comment would be useful.) Sorry, "yes" of course. Total blindness to what you wrote on my part. -- Regards, Hallvard

1 0

Re: (ITS#4940) libldap doesn't wait for server's TLS close_notify
by guenther+ldapdev＠sendmail.com 11 May '07

11 May '07

On Fri, 11 May 2007, Howard Chu wrote: > That sounds like you're seeing a bug in the kernel's TCP stack then. A > TCP close sends a FIN to the other end and is required to wait for the > FIN to be ACK'd before the connection can be torn down. (Subject to 2MSL > timeout.) That is most certainly not our problem. The FIN sent by the client *is* ACKed by the server. The data sent by the client is reliably delivered. The issue is the behavior when data is sent to a endpoint which has already called close(). The data can't be delivered to the application, so the kernel send back a RST to inform the other end of the data loss. That issue---the data loss---is a direct result of the server sending a TLS close_notify and client not reading it before closing the socket. Unless one of those changes, a RST must be generated to report the data loss to the sender. All the UNIX versions that I have tried behave as described. If this is a bug in TCP stacks, it is *very* well entrenched. Philip Guenther

1 0

Re: (ITS#4930) slaptest should be quiet on success
by ando＠sys-net.it 11 May '07

11 May '07

jsafranek(a)redhat.com wrote: > The 'slaptest' tool is a bit verbose, it sends 'config file testing succeeded' > to stderr. IMHO it should do not output anything, especially to stderr, if > everything is all right. > > Here is a small patch, causing the slaptest to display the aforementioned > message only if -v switch is used: > > Index: servers/slapd/slaptest.c > =================================================================== > RCS file: /repo/OpenLDAP/pkg/ldap/servers/slapd/slaptest.c,v > retrieving revision 1.9 > diff -r1.9 slaptest.c > 107c107,108 > < fprintf( stderr, "config file testing succeeded\n"); > --- >> if (verbose) >> fprintf( stderr, "config file testing succeeded\n"); Your issue may make sense in some cases, but I'd rather reverse its logic and avoid printing any message only when explicitly requested to be "quiet" (e.g. adding a -Q switch?) p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#4940) libldap doesn't wait for server's TLS close_notify
by hyc＠symas.com 11 May '07

11 May '07

guenther+ldapdev(a)sendmail.com wrote: > Full_Name: Philip Guenther > Version: 2.3.27 > OS: Linux and Solaris > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (64.58.1.252) > > > [I vaguely recall seeing a report of this issue in the archives of one of the > mailing lists, but I can no longer find the original.] > > If you trace the packets sent when you use, for example, ldapsearch against a > server on a different host, using either the -Z option to do TLS or using an > ldaps URI, you'll discover that the TCP connection is actually reset instead of > being closed cleanly: the client sends TCP RSTs in response to the server's > final packets. > > This is because libldap uses the following sequence when unbind a TLS or SSL > connection: > 1) send the unbind request (over the TLS or SSL layer) > 2) call SSL_shutdown(), sending the TLS close_notify alert > 3) call close() > > After receiving the close_notify alert from step (2), the server sends back its > own close_notify alert and then calls close(). However, because the client > didn't wait for the server's response before calling close() on its end, the > client's TCP stack considers the TCP connection to already be gone and responds > with the RST packets. This occurs with Linux and Solaris clients and probably > most other unices: the response to packets after a close() doesn't vary in my > experience. That sounds like you're seeing a bug in the kernel's TCP stack then. A TCP close sends a FIN to the other end and is required to wait for the FIN to be ACK'd before the connection can be torn down. (Subject to 2MSL timeout.) That is most certainly not our problem. -- -- Howard Chu Chief Architect, 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#4956) slapd cores with a SEGFAULT after a failed proxy authorization
by hyc＠symas.com 11 May '07

11 May '07

pturgyan(a)umich.edu wrote: > Full_Name: Paul Turgyan > Version: 2.3.35 > OS: linux - 2.6 kernal > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (141.213.231.201) > slapd cores with a SEGFAULT after a failed proxy authorization, > with a core file like: This was already reported in ITS#4954 and is fixed in HEAD. Simply NULLing out the pointer will introduce a memory leak. This ITS will be closed as a dup of #4954. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

← Newer
1
...
9
10
11
12
13
14
15
16
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs May 2007