openldap-bugs January 2007

openldap-bugs@openldap.org

29 participants
118 discussions

Re: (ITS#4797) back-bdb crashes during test34-translucent
by ando＠sys-net.it 08 Jan '07

08 Jan '07

ando(a)sys-net.it wrote: > Apparently, the cache lru is not initialized. Backtrace: > works for me, now. Thanks, p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. 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#4798) idassert mode=self doesn't proxyauthz for anonymous operations
by ando＠sys-net.it 08 Jan '07

08 Jan '07

Full_Name: Pierangelo Masarati Version: HEAD,re23 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando See <http://www.openldap.org/lists/openldap-software/200701/msg00062.html>. A fix is coming.

1 0

Re: (ITS#4783) ldap_sasl_bind() is not asynchronous
by ando＠sys-net.it 08 Jan '07

08 Jan '07

ando(a)sys-net.it wrote: > fcusack(a)fcusack.com wrote: >> But still you can do the bind async, and just close the fd on the client >> side on timeout. I don't see why connect() timeout can't be handled >> the same way. (ignoring the problem that there is no API call AFAICT >> to just drop the connection) >> > I'll note that there's been some interest in that area --- I loosely > have the same need (see > <http://www.openldap.org/lists/openldap-devel/200611/msg00000.html>) but > unfortunately it's not in my priority list, considering that it might > have relevant impact on the client library. Eventually, this got on top of my priority list, and it's now implemented in HEAD. One needs to: - set LDAP_OPT_NETWORK_TIMEOUT to a value greater than 0 - set LDAP_OPT_CONNECT_ASYNC to TRUE - perform the first operation asynchronously (e.g. ldap_sasl_bind(3)) the library call might return LDAP_X_CONNECTING if poll(2)'ing after connect(2) didn't succeed yet and LDAP_OPT_NETWORK_TIMEOUT didn't expire yet. In that case, the client should resubmit the request until it either succeeds or LDAP_OPT_NETWORK_TIMEOUT expires. Note that, right now, there's no means to set LDAP_OPT_CONNECT_ASYNC other than via ldap_set_option(3), and none is foreseen, because only specially crafted clients would be able to handle LDAP_X_CONNECTING appropriately. Please test. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. 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#4797) back-bdb crashes during test34-translucent
by ando＠sys-net.it 08 Jan '07

08 Jan '07

Full_Name: Pierangelo Masarati Version: HEAD OS: Linux SuSE 10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (131.175.154.35) Submitted by: ando Apparently, the cache lru is not initialized. Backtrace: masarati@xxx:~/yyy/ldap-devel/tests> gdb ../servers/slapd/slapd core.1900 GNU gdb 6.3 <snip> #0 0x00000000004f9e13 in bdb_cache_delete_internal (cache=0x817b50, e=0x8efbc0, decr=1) at cache.c:1240 1240 LRU_DEL( cache, e ); (gdb) bt #0 0x00000000004f9e13 in bdb_cache_delete_internal (cache=0x817b50, e=0x8efbc0, decr=1) at cache.c:1240 #1 0x00000000004f9bdf in bdb_cache_delete (bdb=0x817af0, e=0x8c5bf8, locker=2147483683, lock=0x41801820) at cache.c:1155 #2 0x00000000004fde8f in bdb_delete (op=0x8d94e0, rs=0x41801d50) at delete.c:520 #3 0x00000000004b0011 in overlay_op_walk (op=0x8d94e0, rs=0x41801d50, which=op_delete, oi=0x819310, on=0x0) at backover.c:507 #4 0x00000000004b0215 in over_op_func (op=0x8d94e0, rs=0x41801d50, which=op_delete) at backover.c:559 #5 0x00000000004b035f in over_op_delete (op=0x8d94e0, rs=0x41801d50) at backover.c:611 #6 0x00000000004580ca in fe_op_delete (op=0x8d94e0, rs=0x41801d50) at delete.c:180 #7 0x0000000000457cbc in do_delete (op=0x8d94e0, rs=0x41801d50) at delete.c:91 #8 0x0000000000438689 in connection_operation (ctx=0x41801e90, arg_v=0x8d94e0) at connection.c:1128 #9 0x0000000000438b6c in connection_read_thread (ctx=0x41801e90, argv=0xd) at connection.c:1256 #10 0x0000000000592587 in ldap_int_thread_pool_wrapper (xpool=0x7d99a0) at tpool.c:704 #11 0x00002aaaab0befa5 in start_thread () from /lib64/tls/libpthread.so.0 #12 0x00002aaaab28acb2 in clone () from /lib64/tls/libc.so.6 #13 0x0000000000000000 in ?? () <snip> (gdb) p cache[0] $1 = {c_eifree = 0x0, c_idtree = 0x8ebaa0, c_lruhead = 0x0, c_lrutail = 0x0, c_dntree = {bei_parent = 0x0, bei_id = 0, bei_lockpad = 0 '\0', bei_state = 128, bei_finders = 0, bei_nrdn = {bv_len = 0, bv_val = 0x0}, bei_e = 0x0, bei_kids = 0x8ec040, bei_kids_mutex = {__m_reserved = 0, __m_count = 0, __m_owner = 0x0, __m_kind = 0, __m_lock = {__status = 0, __spinlock = 0}}, bei_lrunext = 0x0, bei_lruprev = 0x0}, c_maxsize = 1000, c_cursize = 4, c_minfree = 1, c_eiused = 3, c_leaves = 1, c_purging = 0, c_locker = 6, c_rwlock = 0x817db0, c_lru_mutex = { __m_reserved = 1, __m_count = 0, __m_owner = 0x100000771, __m_kind = 0, __m_lock = {__status = 0, __spinlock = 0}}, c_count_mutex = { __m_reserved = 0, __m_count = 0, __m_owner = 0x0, __m_kind = 0, __m_lock = {__status = 0, __spinlock = 0}}, c_eifree_mutex = { __m_reserved = 0, __m_count = 0, __m_owner = 0x0, __m_kind = 0, __m_lock = {__status = 0, __spinlock = 0}}} (gdb) p e[0] $2 = {bei_parent = 0x8e2cc0, bei_id = 7, bei_lockpad = 0 '\0', bei_state = 139, bei_finders = 0, bei_nrdn = {bv_len = 11, bv_val = 0x8e26f0 "uid=someguy"}, bei_e = 0x8c5bf8, bei_kids = 0x0, bei_kids_mutex = {__m_reserved = 1, __m_count = 0, __m_owner = 0x100000771, __m_kind = 0, __m_lock = {__status = 0, __spinlock = 0}}, bei_lrunext = 0x0, bei_lruprev = 0x0}

1 0

Re: (ITS#4494) connections are not asynchrounous
by ando＠sys-net.it 08 Jan '07

08 Jan '07

lrm(a)interlinknetworks.com wrote: > I have already tried this. It does not have any affect on SSL connection > negotitation. > > There is a very interseting comment in the code which indicates someone was > aware of the problem. From the 2.3.20 source distribution, file > libraries/libldap/tls.c (line 1445): > > /* > * Fortunately, the lib uses blocking io... > */ > if ( ldap_int_tls_connect( ld, conn ) < 0 ) { > ld->ld_errno = LDAP_CONNECT_ERROR; > return (ld->ld_errno); > } > > And in ldap_int_tls_connect(), there is a call to SSL_connect( ssl ) that has no > provision for asynchronous operation. There is no setting of the non-blocking > option that I can find in this code sequence. > > > To reproduce the problem, simply point your ldaps: URL to a TCP server port that > accepts connections, and does nothing with them. The LDAP client will hang > forever (or until the server ephemeral port is closed). Is it an option for you to use Start TLS instead of ldaps? In this case, code in right HEAD should fix all non-blocking issues, as soon as you specify a network timeout and LDAP_OPT_CONNECT_ASYNC (undocumented yet, it's been committed just hours ago). The usage I suggest is to set LDAP_OPT_NETWORK_TIMEOUT to a positive value; then set LDAP_OPT_CONNECT_ASYNC to TRUE before performing the first operation, and reset it to FALSE after the first operation succeeds. In your case, the first operation would be ldap_start_tls[_s](3). p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. 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#4786) back-sql searching with dn attribute selected causes object class violation
by ando＠sys-net.it 08 Jan '07

08 Jan '07

robb(a)wtg.cw.com wrote: > Pierangelo Masarati wrote: >> In any case, since the behavior you report is very data and meta-data >> dependent, you don't provide enough info for debugging, and at a very >> first glance this is not indicative of a software bug. > > Pierangelo, > > the problem is indeed with the meta-data: > > the object at the root of the sql tree "dc=sql,dc=example,dc=org" was > defined purely as dcObject, it needs a structural objectClass in order > to be valid. > > If we define it as an organizationalUnit and dcObject (using > ldap_entry_objclasses) then all works as expected. > > Oddly doing the opposite doesn't seem to work. Because somewhere a constraint stepped in, which requires objectClasses in ldap_objectclasses to be structural; it makes sense, all in all. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. 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#4786) back-sql searching with dn attribute selected causes object class violation
by robb＠wtg.cw.com 08 Jan '07

08 Jan '07

Pierangelo Masarati wrote: > In any case, since the behavior you report is very data and meta-data > dependent, you don't provide enough info for debugging, and at a very > first glance this is not indicative of a software bug. Pierangelo, the problem is indeed with the meta-data: the object at the root of the sql tree "dc=sql,dc=example,dc=org" was defined purely as dcObject, it needs a structural objectClass in order to be valid. If we define it as an organizationalUnit and dcObject (using ldap_entry_objclasses) then all works as expected. Oddly doing the opposite doesn't seem to work. Many thanks, Rob -- Robert Brooks, Network Manager, Cable & Wireless UK <robb(a)wtg.cw.com> http://wtg.cw.com/ Tel: +44 (0)20 7339 8600 Fax: +44 (0)20 7339 8601 - "What was your username again?" - BOFH -

1 0

(ITS#4796) Contribution: JLDAP support for simple paging of results (RFC 2696)
by radovan＠skolnik.info 06 Jan '07

06 Jan '07

Full_Name: Radovan Skolnik Version: JLDAP CVS version OS: Windows/Java URL: http://www.skolnik.info/LDAPPagedResults.zip Submission from: (NULL) (82.119.120.128) Hello, I hope this is the right place to make this submission ;-) Recently I found that JLDAP does not support simple paging mechanism via control as stated in RFC2696 (control OID 1.2.840.113556.1.4.319). So I made an attempt to implement it and it seems to me it works as it's supposed to. I would like to contribute it to the project for the benefit of others. The files can be found at http://www.skolnik.info/LDAPPagedResults.zip If there is something more needed from me please let me know. Best regards Radovan Skolnik

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs January 2007