openldap-bugs

openldap-bugs@openldap.org

1 participants
20995 discussions

Re: (ITS#4951) [contrib] RADIUS password module fixes
by ando＠sys-net.it 13 May '07

13 May '07

richton(a)nbcs.rutgers.edu wrote: > * libradius makes use of MT-Unsafe calls, so a protecting mutex is added. applied to HEAD > * config_filename could be passed to rad_config without initialization (when > accepting the default). rejected: global variables are always zeroed. Please test. Thanks, 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#4957) destroying uninitialized mutexed after failed startup
by ando＠sys-net.it 13 May '07

13 May '07

h.b.furuseth(a)usit.uio.no wrote: > (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?) Commit; if appropriate, note in CHANGES. Someone else (the Chief Architect) will move tags. 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

(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 12 May '07

12 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

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