openldap-bugs

openldap-bugs@openldap.org

1 participants
20962 discussions

(ITS#6111) Assert in connection_state_closing
by luca.scamoni＠sys-net.it 13 May '09

13 May '09

Full_Name: Luca Scamoni Version: 2.4.16 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.63.140.131) Met a new assert, this time in connection_state_closing. OpenLDAP 2.4.16 + patches (aligned to RELENG). Master/Slave configuration with syncrepl in refreshAndPersist. Any further info available. (gdb) bt full #0 0x006487a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 No symbol table info available. #1 0x002ea7a5 in raise () from /lib/tls/libc.so.6 No symbol table info available. #2 0x002ec209 in abort () from /lib/tls/libc.so.6 No symbol table info available. #3 0x002e3d91 in __assert_fail () from /lib/tls/libc.so.6 No symbol table info available. #4 0x0807864f in connection_state_closing (c=0xb7ef3b04) at ../../../servers/slapd/connection.c:704 state = -1209058380 __PRETTY_FUNCTION__ = "connection_state_closing" #5 0x0808d721 in send_ldap_ber (op=0x36faf30, ber=0x36faae0) at ../../../servers/slapd/result.c:148 conn = (Connection *) 0xb7ef3b04 bytes = 891791 ret = 0 closing = 0 #6 0x0809150d in slap_send_search_entry (op=0x36faf30, rs=0x36facb0) at ../../../servers/slapd/result.c:1247 berbuf = { buffer = "\002\000\001\000\000\000\000\000ÿÿÿÿ\000\000\000\000\000\000\000\000üÀ¯Q\213\\œQ\222]œQ\000\000\000\000\000\000\000\000\bw\201\f\004~8\000hÒä\thÒä\tr\000\000\000\000@\000\000 ³>\000[Y0\000L°¯Q\003\b\024\bX«o\003\200°¯Qø«o\003\v\000\000\000\025\000\000\000hÒä\t\000\000\000\000H|\tJhÒä\tr\000\000\000àx8\000D«o\003\000\000\000\000\000\000\000\000àvNu\bw\201\f ¬o\003\000\000\000\000\001\000\000\000\200°¯QøvNu0\217ô\000\000\000\000\000Aw\016\bX?\003\000\003\002\000\000\033Ò{\002\001\000\000\000\005\000\000\0000\217ô\000"..., ialign = 65538, lalign = 65538, falign = 9.18382988e-41, dalign = 3.2380074297143616e-319, palign = 0x10002 <Address 0x10002 out of bounds>} ber = (BerElement *) 0x36faae0 a = (Attribute *) 0x0 i = 1 j = 3 rc = 891791 bytes = 8080 userattrs = 1 acl_state = {as_vi_acl = 0x0, as_vd_acl = 0x0, as_vd_ad = 0x9a65858, as_recorded = ACL_STATE_RECORDED, as_vd_acl_count = 0, as_result = 1, as_fe_done = 0} attrsonly = 0 ad_entry = (AttributeDescription *) 0x9a68f58 e_flags = (char **) 0x0 #7 0x00406da2 in syncprov_sendresp (op=0x36faf30, opc=0x36fad90, so=0x476b9080, e=0x36fadd4, mode=2) at ../../../../servers/slapd/overlays/syncprov.c:834 on = (slap_overinst *) 0x9b3c998 rs = {sr_type = REP_SEARCH, sr_tag = 0, sr_msgid = 0, sr_err = 0, sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0, sr_ctrls = 0x36faca8, sr_un = { sru_sasl = {r_sasldata = 0x0}, sru_extended = {r_rspoid = 0x0, r_rspdata = 0x22}, sru_search = {r_entry = 0x0, r_attr_flags = 34, r_operational_attrs = 0x54370acc, r_attrs = 0x43366f30, r_nentries = 0, r_v2ref = 0x0}}, sr_flags = 0} ctrls = {0x51afb08c, 0x0} cookie = {bv_len = 52, bv_val = 0x51afb04c "rid=002,csn=20090512134019.302018Z#000000#000#000000"} csns = {{bv_len = 40, bv_val = 0x450749fb "20090512134019.302018Z#000000#000#000000"}, {bv_len = 0, bv_val = 0x0}} e_uuid = {e_id = 0, e_name = {bv_len = 0, bv_val = 0x0}, e_nname = {bv_len = 0, bv_val = 0x0}, e_attrs = 0x36fac40, e_ocflags = 0, e_bv = { bv_len = 0, bv_val = 0x0}, e_private = 0x0} a_uuid = {a_desc = 0x9a65d50, a_vals = 0x0, a_nvals = 0x36fadac, a_numvals = 0, a_flags = 0, a_next = 0x0} __PRETTY_FUNCTION__ = "syncprov_sendresp" #8 0x00407160 in syncprov_qplay (op=0x36faf30, so=0x476b9080) at ../../../../servers/slapd/overlays/syncprov.c:913 on = (slap_overinst *) 0x9b3c998 sr = (syncres *) 0x45074928 e = (Entry *) 0x54546b2c opc = {son = 0x9b3c998, smatches = 0x36fb008, smt = 0x36fadf8, sdn = {bv_len = 76, bv_val = 0x45074950 "ou=Actalis CA per Firma Digitale Qualificata,o=CNIPA,dc=a,dc=prod,dc=actalis"}, sndn = {bv_len = 76, bv_val = 0x4507499d "ou=actalis ca per firma digitale qualificata,o=cnipa,dc=a,dc=prod,dc=actalis"}, suuid = {bv_len = 16, bv_val = 0x450749ea "\215è#\001µÀ\021Ú\200\006\207öæyñœ020090512134019.302018Z#000000#000#000000"}, sctxcsn = {bv_len = 40, bv_val = 0x450749fb "20090512134019.302018Z#000000#000#000000"}, osid = 0, rsid = 0, sreference = 0} rc = 0 #9 0x00407372 in syncprov_qtask (ctx=0x36fb210, arg=0x476b9080) at ../../../../servers/slapd/overlays/syncprov.c:971 so = (syncops *) 0x476b9080 opbuf = {ob_op = {o_hdr = 0x36fb008, o_tag = 99, o_time = 1242135600, o_tincr = 0, o_bd = 0x36fae20, o_req_dn = {bv_len = 23, bv_val = 0x43366f93 "dc=a,dc=prod,dc=actalis"}, o_req_ndn = {bv_len = 23, bv_val = 0x43366fab "dc=a,dc=prod,dc=actalis"}, o_request = {oq_add = { rs_modlist = 0x2, rs_e = 0x0}, oq_bind = {rb_method = 2, rb_cred = {bv_len = 0, bv_val = 0xffffffff <Address 0xffffffff out of bounds>}, rb_edn = { bv_len = 4294967295, bv_val = 0x0}, rb_ssf = 0, rb_mech = {bv_len = 1127640880, bv_val = 0x47abcff8 "\207"}}, oq_compare = {rs_ava = 0x2}, oq_modify = {rs_mods = {rs_modlist = 0x2, rs_no_opattrs = 0 '\0'}, rs_increment = -1}, oq_modrdn = {rs_mods = {rs_modlist = 0x2, rs_no_opattrs = 0 '\0'}, rs_deleteoldrdn = -1, rs_newrdn = {bv_len = 4294967295, bv_val = 0x0}, rs_nnewrdn = {bv_len = 0, bv_val = 0x43366f30 "\001"}, rs_newSup = 0x47abcff8, rs_nnewSup = 0xf}, oq_search = {rs_scope = 2, rs_deref = 0, rs_slimit = -1, rs_tlimit = -1, rs_limit = 0x0, rs_attrsonly = 0, rs_attrs = 0x43366f30, rs_filter = 0x47abcff8, rs_filterstr = {bv_len = 15, bv_val = 0x43366fc3 "(objectClass=*)"}}, oq_abandon = {rs_msgid = 2}, oq_cancel = {rs_msgid = 2}, oq_extended = {rs_reqoid = {bv_len = 2, bv_val = 0x0}, rs_flags = -1, rs_reqdata = 0xffffffff}, oq_pwdexop = {rs_extended = {rs_reqoid = {bv_len = 2, bv_val = 0x0}, rs_flags = -1, rs_reqdata = 0xffffffff}, rs_old = {bv_len = 0, bv_val = 0x0}, rs_new = {bv_len = 1127640880, bv_val = 0x47abcff8 "\207"}, rs_mods = 0xf, rs_modtail = 0x43366fc3}}, o_abandon = 0, o_cancel = 0, o_groups = 0x0, o_do_not_cache = 1 '\001', o_is_auth_check = 0 '\0', o_dont_replicate = 0 '\0', o_acl_priv = ACL_NONE, o_nocaching = 0 '\0', o_delete_glue_parent = 0 '\0', o_no_schema_check = 0 '\0', o_no_subordinate_glue = 0 '\0', o_ctrlflag = '\0' <repeats 14 times>, "\003", '\0' <repeats 16 times>, o_controls = 0x36fb130, o_authz = { sai_method = 128, sai_mech = {bv_len = 0, bv_val = 0x0}, sai_dn = {bv_len = 34, bv_val = 0x43366f70 "cn=manager,dc=a,dc=prod,dc=actalis"}, sai_ndn = { bv_len = 34, bv_val = 0x43366f70 "cn=manager,dc=a,dc=prod,dc=actalis"}, sai_ssf = 0, sai_transport_ssf = 0, sai_tls_ssf = 0, sai_sasl_ssf = 0}, o_ber = 0x0, o_res_ber = 0x0, o_callback = 0x0, o_ctrls = 0x0, o_csn = {bv_len = 0, bv_val = 0x0}, o_private = 0x0, o_extra = {slh_first = 0x0}, o_next = {stqe_next = 0x0}}, ob_hdr = {oh_opid = 1, oh_connid = 18793, oh_conn = 0xb7ef3b04, oh_msgid = 2, oh_protocol = 3, oh_tid = 53455776, oh_threadctx = 0x36fb210, oh_tmpmemctx = 0xc817708, oh_tmpmfuncs = 0x8172f00, oh_counters = 0x9bc2c28, oh_log_prefix = "conn=18793 op=1", '\0' <repeats 240 times>}, ob_controls = {0x0 <repeats 32 times>}} op = (Operation *) 0x36faf30 be = {bd_info = 0x9b3c898, bd_self = 0x9b3b788, be_ctrls = "\000\001\001\001\000\001\000\000\001\000\000\001\001\000\001\000\001", '\0' <repeats 15 times>, "\001", be_flags = 2312, be_restrictops = 0, be_requires = 0, be_ssf_set = {sss_ssf = 0, sss_transport = 0, sss_tls = 0, sss_sasl = 0, sss_update_ssf = 0, sss_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 0}, be_suffix = 0x9b3b5b8, be_nsuffix = 0x9b3c680, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_schemandn = {bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 34, bv_val = 0x9b3c718 "cn=Manager,dc=a,dc=prod,dc=actalis"}, be_rootndn = {bv_len = 34, bv_val = 0x9b3c758 "cn=manager,dc=a,dc=prod,dc=actalis"}, be_rootpw = {bv_len = 6, bv_val = 0x9b3c548 "secret"}, be_max_deref_depth = 15, be_def_limit = {lms_t_soft = 3600, lms_t_hard = 0, lms_s_soft = 500, lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x0, be_acl = 0x0, be_dfltaccess = ACL_READ, be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x0, be_pending_csn_list = 0x9b7e488, be_pcl_mutex = {__m_reserved = 0, __m_count = 0, __m_owner = 0x0, __m_kind = 0, __m_lock = {__status = 0, __spinlock = 0}}, be_syncinfo = 0x0, be_pb = 0x0, be_cf_ocs = 0xf5f940, be_private = 0x9b3b888, be_next = {stqe_next = 0x9b3cb98}} rc = 135718720 #10 0x0017c389 in ldap_int_thread_pool_wrapper (xpool=0x9a6bab0) at ../../../libraries/libldap_r/tpool.c:663 pool = (struct ldap_int_thread_pool_s *) 0x9a6bab0 task = (ldap_int_thread_task_t *) 0x9b890c0 work_list = (ldap_int_tpool_plist_t *) 0x9a6bb30 ctx = {ltu_id = 57654176, ltu_key = {{ltk_key = 0x80793bb, ltk_data = 0xca920d8, ltk_free = 0x80791ab <conn_counter_destroy>}, { ltk_key = 0x80e66d5, ltk_data = 0xc817708, ltk_free = 0x80e64e8 <slap_sl_mem_destroy>}, {ltk_key = 0x8092ceb, ltk_data = 0xcad6508, ltk_free = 0x8092c48 <slap_op_q_destroy>}, {ltk_key = 0x9b856d0, ltk_data = 0xca96970, ltk_free = 0xdf2796 <bdb_reader_free>}, {ltk_key = 0x9b7e498, ltk_data = 0xc8ebe68, ltk_free = 0xdf2796 <bdb_reader_free>}, {ltk_key = 0xde0b96, ltk_data = 0x4e175008, ltk_free = 0xde0b6b <search_stack_free>}, { ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 26 times>}} kctx = (ldap_int_thread_userctx_t *) 0x0 i = 32 keyslot = 429 hash = 5950893 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #11 0x008ad3cc in start_thread () from /lib/tls/libpthread.so.0 No symbol table info available. #12 0x0038bc3e in clone () from /lib/tls/libc.so.6 No symbol table info available.

1 0

Re: (ITS#6106) Unable to start LDAP Service in Windows
by hyc＠symas.com 12 May '09

12 May '09

Jemmy.Sentonius(a)infor.com wrote: > Full_Name: Jemmy Sentonius > Version: 2.2.29 > OS: Windows 2003 Server > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (211.24.230.162) > > > > 1) Start the LDAP Service in Windows (logon as Domain Administrator) > 2) System will prompt error: > Windows could not start the InforSecurity LDAP on local computer. For more > information, review the system event log. If this is non-Microsoft Service, > contact the service vendor, and refer to service-specific error code 16. > > 3) Go to Windows Event Viewer, System Log > Notice that there's an error log with description: > The InforSecurity LDAP Service terminated with service-specific error 16 > (0x10) The OpenLDAP Project dropped support for OpenLDAP 2.2 in 2005. This ITS will be closed. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#6110) GSSAPI signing/encryption for unsuspectingly applications
by mikbec＠web.de 12 May '09

12 May '09

Full_Name: Mike Becher Version: 2.4.16 or HEAD OS: Linux URL: ftp://ftp.openldap.org/incoming/mike-becher-090512.libraries-libldap.patch Submission from: (NULL) (84.150.169.165) patch file name: mike-becher-090512.libraries-libldap-gssapi.1.patch patch subject: GSSAPI signing/encryption for unsuspectingly applications ftp://ftp.openldap.org/incoming/mike-becher-090512.libraries-libldap.patch This patch (see above) introduces a function hook and an additional ldap.conf or ldaprc option GSSAPI_TRY_GSSAPI_BIND_S_IN_SASL_INTERACTIVE_BIND_S which enables unsuspectingly applications to make use of GSSAPI based authentification, signing, and/or encryption. This is very useful if you are connected to MS Active Directory with LDAP server signing is required (means is switched on) and your software (like for example pam_ldap or nss_ldap) doesn't know about that requirement. Additionally if a user does not want use this feature s/he can it switch off on demand. Excerpt from manual page enhancement: On technical view this (hook and option) enables call of ldap_gssapi_bind_s() at the beginning of ldap_sasl_interactive_bind_s(). If ldap_gssapi_bind_s() returns with LDAP_SUCCESS the SASL code of ldap_sasl_interactive_bind_s() will be skipped. In other case ldap_sasl_interactive_bind_s() will be executed. If this option is switch on and an application makes use of ldap_sasl_interactive_bind_s() but doesn't know anything about ldap_gssapi_bind_s() it is able to use GSSAPI signing and encryption. NOTE(s): This patch makes patches of * ITS#6091: missing implementation of "switch off" functionality of GSSAPI OPTIONS * ITS#6092: correct string problem in guess_service_principal() * ITS#6093: correct hostname resolving problem in guess_service_principal() obsolete. Thanks to Hallvard B Furuseth for its comments to ITS#6092 which results in a rewrite of that code snipset.

1 0

(ITS#6109) readonly mode allows ldappaswd
by lacoste＠miage.univ-paris12.fr 12 May '09

12 May '09

Full_Name: Thierry Lacoste Version: 2.4.16 OS: FreeBSD 6.4 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (86.203.226.27) A server in readonly mode allows password changes via ldappasswd.

1 0

Re: (ITS#6104) race condition with cancel operation
by hyc＠symas.com 11 May '09

11 May '09

Hallvard B Furuseth wrote: > hyc(a)symas.com writes: >>> slapd/cancel.c sets o_abandon before o_cancel. Thus it's possible for >>> the canceled operation to obey o_abandon before o_cancel gets set. >> >> Cancel is just best-effort, why not just set o_cancel before o_abandon? > > Memory coherence. Without mutex protection, the cancelled thread might > still see the o_abandon change before the o_cancel change. And thus not > send a response, nor update info for the Cancel operation to react to. > I'd prefer to condense it all into a bitfield. We already ensure that the c_mutex is held when setting these flags. It would be a lot of overhead to grab the mutex just to read the flag, and would require additional analysis to make sure the new locking behavior doesn't introduce new deadlocks. -- -- Howard Chu CTO, 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#6104) race condition with cancel operation
by h.b.furuseth＠usit.uio.no 11 May '09

11 May '09

hyc(a)symas.com writes: >> slapd/cancel.c sets o_abandon before o_cancel. Thus it's possible for >> the canceled operation to obey o_abandon before o_cancel gets set. > > Cancel is just best-effort, why not just set o_cancel before o_abandon? Memory coherence. Without mutex protection, the cancelled thread might still see the o_abandon change before the o_cancel change. And thus not send a response, nor update info for the Cancel operation to react to. -- Hallvard

1 0

(ITS#6108) unique overlay and rootdn
by mfn＠fs-etit.de 11 May '09

11 May '09

Full_Name: Christopher Dyck Version: 2.4.11 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (130.83.183.3) I found a strange behavior in the unique overlay. unique overlay only works, when a rootdn is specified in the slapd.conf, because the unique_search function uses the rootdn for searching. (took me hours to determine why my configuration didn't do it's job) Isn't it more reasonable to use the dn with which the add or modify is performed? Or mention this circumstance at least in the manpage?!

1 0

Re: (ITS#6107) Manual pages do not mention -e option
by masarati＠aero.polimi.it 11 May '09

11 May '09

rein(a)OpenLDAP.org wrote: > Full_Name: Rein Tollevik > Version: 2.4.16 > OS: Irrelevant > URL: > Submission from: (NULL) (81.93.160.250) > Submitted by: rein > > > The manual pages for (at least) ldapmodify, ldapmodrdn and ldapdelete do not > mention the "-e control" option, nor is the private "-E" documented for > ldapmodify. > > A lot of the options accepted by the ldap* tools are common to them all. Should > they be documented in a separate man page referred to by the tools manuals, or > at least included from a common source? I favor documenting everything in each man page, to limit the amount of redirection (when reading man pages, one wants to quickly find an answer to a specific problem, not learn everything about LDAP :). Documentation should be concise enough to minimally impact the amount one needs to read to learn how to *use* those controls. To learn about the purpose and the details of those controls, references should be used. My 2c. p.

1 0

(ITS#6107) Manual pages do not mention -e option
by rein＠OpenLDAP.org 11 May '09

11 May '09

Full_Name: Rein Tollevik Version: 2.4.16 OS: Irrelevant URL: Submission from: (NULL) (81.93.160.250) Submitted by: rein The manual pages for (at least) ldapmodify, ldapmodrdn and ldapdelete do not mention the "-e control" option, nor is the private "-E" documented for ldapmodify. A lot of the options accepted by the ldap* tools are common to them all. Should they be documented in a separate man page referred to by the tools manuals, or at least included from a common source? -- Rein Tollevik Basefarm AS

1 0

Re: (ITS#6059) Abandon syncprov race condition?
by rein＠OpenLDAP.org 11 May '09

11 May '09

hyc(a)symas.com wrote: > rein(a)OpenLDAP.org wrote: >> I've had two cases where a delete operation was performed on the master without >> being replicated to its consumers, which so far appear to be cases of possible >> connection lost (abandon) race conditions. The log (level: stats) shows the >> "DEL" message of the entry, immediately followed by a "closed (connection lost)" >> message on the connection. Note: No "RESULT" message was logged. >> >> I haven't looked very much into this, but my theory so far is that syncprov >> skipped replicating of the delete op after noticing the abandon resulting from >> loosing the connection, even though the delete had already taken place in the >> local database. That it happened after a delete op might very well have been a >> coincident, this possible race could exist after any modify op for all I know. > >> Do we need some sort of o_committed flag that can be used to prevent o_abandon >> from being set or acted upon? Or handle o_abandon more like o_cancel, i.e with >> multiple values, including "too late"? > > No. What good can that do, since the connection has already been lost? > > It doesn't matter if syncprov fails to send an update to a consumer - the > consumer's cookie state will let it pick up where it left off when it reconnects. It isn't the connection to the syncprov consumer that was lost, it is the connection to the client that made the change. The abandon may cause syncprov to abandon the modify op (in syncprov_op_abandon), and it will definitely cause the entire response callback to be skipped. Which is where syncprov sends updates to its consumers. The change will take place in the local database, but not be replicated, nor will auditlog log it. Accesslog does though, probably since the cleanup callback it enables in accesslog_op_mod explicitly calls its response callback. The syncprov clients will receive updates to the csn when new modifications takes place, i.e the clients must be restarted with the "-c" option to resync their databases. 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