(ITS#6747) LDAP_CONNECTIONLESS nitpicks
by h.b.furuseth@usit.uio.no
Full_Name: Hallvard B Furuseth
Version: HEAD
OS:
URL:
Submission from: (NULL) (129.240.6.233)
Submitted by: hallvard
Bug:
slapd/daemon.c outputs a berval instead of berval.bv_val.
Compiler warnings:
slapd/connection.c needs lber-int.h for ber_int_sb_read().
libldap/<abandon.c, search.c> pass a struct sockaddr* to a char*.
Fixing.
12 years, 9 months
Re: (ITS#6714) Patch - Mozilla NSS - implement full non-blocking semantics
by rmeggins@redhat.com
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-semantic...
>>
>>
>> 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.
>>
>>
>>
>>
>
>
12 years, 9 months
Re: (ITS#6746) broken slapo-translucent failure handling
by h.b.furuseth@usit.uio.no
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
12 years, 9 months
(ITS#6746) broken slapo-translucent failure handling
by h.b.furuseth@usit.uio.no
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.
12 years, 9 months
(ITS#6745) HEAD emfile race condition -> slapd stopping listening?
by h.b.furuseth@usit.uio.no
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.
12 years, 9 months
Re: (ITS#6476) Failure to delete entry with multi-master replication
by piotr.tarnowski@us.edu.pl
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 ]
12 years, 9 months
Re: (ITS#6731) Scrambled error strings from back-ldif
by h.b.furuseth@usit.uio.no
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
12 years, 9 months