openldap-bugs

openldap-bugs@openldap.org

1 participants
20963 discussions

Re: (ITS#6746) broken slapo-translucent failure handling
by h.b.furuseth＠usit.uio.no 14 Dec '10

14 Dec '10

I've fixed it in HEAD, unless early errors in translucent_search() should be ignored or filter errors should NOT be ignored. -- Hallvard

1 0

Re: (ITS#6238) contrib: lastbind overlay to record timestamp of last successful bind
by michael＠stroeder.com 13 Dec '10

13 Dec '10

Could we have this overlay in contrib/ shipped with 2.4.24? That would be really nice. I've tested it with 2.4.23 and it still seems to work.

1 0

Re: (ITS#6714) Patch - Mozilla NSS - implement full non-blocking semantics
by rmeggins＠redhat.com 13 Dec '10

13 Dec '10

On 12/10/2010 09:03 PM, Howard Chu wrote: > rmeggins(a)redhat.com wrote: >> I "rebased" the patch on top of a recent change: >> revision 1.24 >> date: 2010/12/06 10:31:59; author: hallvard; state: Exp; lines: +5 >> -17 >> ITS#6625 Remove some LDAP_R_COMPILEs > > I didn't quite understand the point of the discussion of SSLv2 clients > in the comments on this patch, but committed it anyway. Thanks. I usually defer to Bob Relyea - he insists this is secure, and will not use SSLv2 if it is explicitly disabled (which it is in the OpenLDAP implementation). > > I would hope that nobody is still using SSLv2 these days. Also if a > StartTLS request fails, then the rest of the code in tlsm.c should > never even be reached; the TLS sockbuf layer wouldn't be installed. In my testing, openldap server was calling the tls session_accept function after the client failed to start tls. Because the failure was on the client side (e.g. a bogus CA cert), the server left the connection flagged with c_needs_tls_accept, and called ldap_pvt_tls_accept() on the next read. I've confirmed this using both openldap 2.4 with openssl and with moznss. openssl also checks for sslv2 incoming connections, but handles error cases better (e.g. it looks for http connections), including the case where the header bytes don't match a known sslv2, v3, or tls handshake. See ssl23_get_client_hello() for more information. > >> The new patch is here: >> ftp://ftp.openldap.org/incoming/openldap-2.4.23-use-non-blocking-semantics-… >> >> >> This patch file is 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#6746) broken slapo-translucent failure handling
by h.b.furuseth＠usit.uio.no 13 Dec '10

13 Dec '10

I wrote: > translucent_search() can return LDAP_COMPARE_FALSE from test_filter(). ...and other error codes too. Should it ignore all other result codes from test_filter() than LDAP_COMPARE_TRUE? -- Hallvard

1 0

(ITS#6746) broken slapo-translucent failure handling
by h.b.furuseth＠usit.uio.no 13 Dec '10

13 Dec '10

Full_Name: Hallvard B Furuseth Version: HEAD OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard translucent_search() can return LDAP_COMPARE_FALSE from test_filter(). Should presumably be LDAP_SUCCESS. It should probably either ignore rc from overlay_op_walk() or not. Currently it ignores rc only if there are entries in tc.list. It doesn't seem to free the remaining entries in tc.list after send_search_entry() failure.

1 0

(ITS#6745) HEAD emfile race condition -> slapd stopping listening?
by h.b.furuseth＠usit.uio.no 13 Dec '10

13 Dec '10

Full_Name: Hallvard B Furuseth Version: HEAD OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard In HEAD slapd/daemon.c, thanks to HEAD's multiple listener support: slap_listener() protects emfile with slap_daemon[0 ].sd_mutex, but slapd_remove() protects it with slap_daemon[id].sd_mutex. Maybe to compensate, slapd_remove() has code which checks if emfile is too big, but nothing checks if it is too small - which looks like slapd might never start listening again. Simplest fix: add this to slapd_remove(): if (id) ldap_pvt_thread_mutex_<lock,unlock>( &slap_daemon[0].sd_mutex ); slap_daemon[0].sd_mutex looks quite contended that way, though. Maybe a separate emfile_mutex is better.

1 0

Re: (ITS#6476) Failure to delete entry with multi-master replication
by piotr.tarnowski＠us.edu.pl 13 Dec '10

13 Dec '10

Hi! We have observed similiar symptoms with OpenLDAP 2.4.23: 2010-12-10T14:56:45+01:00 ldapst2/192.168.10.48 slapd[29363]: [ID 502419 local4.debug] Entry uid=Replicator,dc=us,dc=edu,dc=pl CSN 2 0101208130342.415481Z#000000#008#000000 older or equal to ctx 20101208130342.415481Z#000000#008#000000 2010-12-10T14:56:45+01:00 ldapst2/192.168.10.48 slapd[29363]: [ID 653192 local4.debug] syncprov_search_response: cookie=rid=008,sid= 008,csn=20101202144622.962136Z#000000#007#000000;20101001125631.576652Z#000000#003#000000;20101210135344.096897Z#000000#008#000000 do you have any fixes? Regards -- [ Piotr Tarnowski piotr.tarnowski(a)us.edu.pl ] [ Unix Administrator, University of Silesia, Katowice, Poland ]

1 0

Re: (ITS#6731) Scrambled error strings from back-ldif
by h.b.furuseth＠usit.uio.no 13 Dec '10

13 Dec '10

Howard Chu writes: > It is not an error in ldif_back_add() since rs->sr_text is only used by > send_ldap_result(). Its value upon return from ldif_back_add is irrelevant. Should have been true but isn't - a number of modules reuse SlapReply variables without clearing them:-( -- Hallvard

1 0

Re: (ITS#6660) paged result searches fail to deallocate memory until slapd shutdown
by h.b.furuseth＠usit.uio.no 13 Dec '10

13 Dec '10

I suppose it could be old misnamed ITS#5340. If so, try http://folk.uio.no/hbf/OpenLDAP/slapreply-draft3.diff Compile with CPPFLAGS="-DRS_USE_ASSERT=0". If that helps, the patch needs to work without the CPPFLAGS, but the asserts may be overeager. -- Hallvard

1 0

Re: (ITS#6716) syncprov sessionlog 'sl_mincsn' not assigned a value.
by rein＠OpenLDAP.org 12 Dec '10

12 Dec '10

On 11/19/10 23:55 , cmikk(a)qwest.net wrote: > will evaluate to true in cases where it should not. A quick fix would be to > compare directly against the CSN of the sessionlog's head: An extended version of this fix, which also ensures that the sessionlog is kept in csn order, is now in head. Please test, syncprov.c revision 1.320. Rein

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