openldap-bugs

openldap-bugs@openldap.org

1 participants
20961 discussions

(ITS#8152) mt_flags & MDB_TXN_ERROR is never reset when MDB_MAP_FULL occurs
by dw＠botanicus.net 21 May '15

21 May '15

Full_Name: David Wilson Version: HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.157.85.186) Since the me_txn0 heap allocation is cached across write transactions, when any write transaction fails with MDB_MAP_FULL and causes MDB_TXN_ERROR to be set in me_txn0->mt_flags, it becomes impossible to try another write transaction without reopening the environment, since that bit is never unset anywhere. A simple way to trigger this is attempting to put any value larger than the map size, at which point the environment will always return MDB_BAD_TXN for subsequent write transactions. While MAP_FULL and insufficient validation of input by the application are pretty show-stopper issues already, I doubt wedging the environment state is the most robust response LMDB could muster in this case. It seems MDB_TXN_ERROR wants to be unset in either mdb_txn_abort() or mdb_txn_reset0(). Taking into account the possibility of a parent write transaction also existing, I'm not sure where and how exactly the bit should be unset.

1 0

(ITS#8151) test062 sporadically seg faults
by michael＠stroeder.com 21 May '15

21 May '15

Full_Name: Version: git master 66ab6bafa8e290d842f68e683e3cd3ee63f513be OS: openSUSE Linux x86_64 URL: Submission from: (NULL) (84.178.24.246) test062 in git master sometimes seg faults with hdb and mdb. Core was generated by `/usr/src/michael/openldap-git/master/openldap/servers/slapd/.libs/lt-slapd -s0'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x00007fc961c38c3d in syncprov_free_syncop (so=0x7fc954103950, unlink=1) at syncprov.c:811 811 for ( sop = &so->s_si->si_ops; *sop; sop = &(*sop)->s_next ) { Missing separate debuginfos, use: zypper install cyrus-sasl-crammd5-debuginfo-2.1.26-11.1.x86_64 cyrus-sasl-debuginfo-2.1.26-11.1.x86_64 cyrus-sasl-digestmd5-debuginfo-2.1.26-11.1.x86_64 cyrus-sasl-gs2-debuginfo-2.1.26-11.1.x86_64 cyrus-sasl-gssapi-debuginfo-2.1.26-11.1.x86_64 cyrus-sasl-ntlm-debuginfo-2.1.26-11.1.x86_64 cyrus-sasl-otp-debuginfo-2.1.26-11.1.x86_64 cyrus-sasl-plain-debuginfo-2.1.26-11.1.x86_64 cyrus-sasl-scram-debuginfo-2.1.26-11.1.x86_64 glibc-debuginfo-2.21-5.2.x86_64 krb5-debuginfo-1.13.1-1.2.x86_64 libcom_err2-debuginfo-1.42.12-2.2.x86_64 libdb-4_8-debuginfo-4.8.30-30.2.x86_64 libkeyutils1-debuginfo-1.5.9-47.2.x86_64 libltdl7-debuginfo-2.4.6-2.1.x86_64 libopenssl1_0_0-debuginfo-1.0.1k-3.1.x86_64 libpcre1-debuginfo-8.37-1.1.x86_64 libsasl2-3-debuginfo-2.1.26-11.1.x86_64 libselinux1-debuginfo-2.3-4.3.x86_64 libz1-debuginfo-1.2.8-7.2.x86_64 unixODBC-debuginfo-2.3.2-5.2.x86_64 (gdb) bt full #0 0x00007fc961c38c3d in syncprov_free_syncop (so=0x7fc954103950, unlink=1) at syncprov.c:811 sop = 0x6a626f006769666e sr = 0x62644960 srnext = 0x7fc954003270 ga = 0x7fc954103330 gnext = 0x100000 #1 0x00007fc961c396a0 in syncprov_qtask (ctx=0x7fc962644bf0, arg=0x7fc954103950) at syncprov.c:1005 so = 0x7fc954103950 opbuf = {ob_op = {o_hdr = 0x7fc962644960, o_tag = 99, o_time = 1432200195, o_tin % = 0, o_bd = 0x7fc962644660, o_req_dn = {bv_len = 9, bv_val = 0x7fc95410a9e2 "cn=config"}, o_req_ndn = {bv_len = 9, bv_val = 0x7fc95410a9ec "cn=config"}, o_request = {oq_add = {rs_modlist = 0x2, rs_e = 0xffffffffffffffff}, oq_bind = {rb_method = 2, rb_cred = {bv_len = 18446744073709551615, bv_val = 0x0}, rb_edn = {bv_len = 0, bv_val = 0x0}, rb_ssf = 1410349536, rb_mech = {bv_len = 15, bv_val = 0x7fc95410a9f6 "(objectClass=*)"}}, oq_compar= D {rs_ava = 0x2}, oq_modify = {rs_mods = { rs_modlist = 0x2, rs_no_opattrs = -1 '\377'}, rs_increment = 0}, oq_modrdn = {rs_mods = {rs_modlist = 0x2, rs_no_opattrs = -1 '\377'}, rs_deleteoldrdn = 0, rs_newrdn = {bv_len = 0, bv_val = 0x0}, rs_nnewrdn = {bv_len = 140502675503584, bv_val = 0xf <error: Cannot access memory at address 0xf>}, rs_newSup = 0x7fc95410a9f6, rs_nnewSup = 0x0}, oq_search = {rs_scope = 2, rs_deref = 0, rs_slimit = -1, rs_tlimit = -1, rs_limit = 0x0, rs_attrsonly = 0, rs_attrs = 0x0, rs_filter = 0x7fc9541039e0, rs_filterstr = {bv_len = 15, bv_val = 0x7fc95410a9f6 "(objectClass=*)"}}, oq_abandon = {rs_msgid = 2}, oq_cancel = {rs_msgid = 2}, oq_extended = {rs_reqoid = {bv_len = 2, bv_val = 0xffffffffffffffff <error: Cannot access memory at address 0xffffffffffffffff>}, rs_flags = 0, rs_reqdata = 0x0}, oq_pwdexop = {rs_extended = { rs_reqoid = {bv_len = 2, bv_val = 0xffffffffffffffff <error: Cannot access memory at address 0xffffffffffffffff>}, rs_flags = 0, rs_reqdata = 0x0}, rs_old = {bv_len = 0, bv_val = 0x7fc9541039e0 "\207"}, rs_new = {bv_len = 15, bv_val = 0x7fc95410a9f6 "(objectClass=*)"}, rs_mods = 0x0, rs_modtail = 0x0}}, o_abandon = 0, o_cancel = 0, o_groups = 0x0, o_do_not_cache = 1 '\001', o_is_auth_check = 0 '\000', o_dont_replicate = 0 '\000', o_acl_priv = ACL_NONE, o_nocaching = 0 '\000', o_delete_glue_parent = 0 '\000', o_no_schema_check = 0 '\000', o_no_subordinate_glue = 0 '\000', o_ctrlflag = '\000' <repeats 20 times>, "\001\000\000\000\000\000\000\000\000\000\000", o_controls = 0x7fc962644aa8, o_authz = {sai_method = 128, sai_mech = { bv_len = 0, bv_val = 0x0}, sai_dn = {bv_len = 9, bv_val = 0x7fc95410a9d8 "cn=config"}, sai_ndn = {bv_len = 9, bv_val = 0x7fc95410a9d8 "cn=config"}, 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 = 1003, oh_conn = 0x1bb5730, oh_msgid = 2, oh_protocol = 3, oh_tid = 140502915897088, oh_threadctx = 0x7fc962644bf0, oh_tmpmemctx = 0x7fc954002350, oh_tmpmfuncs = 0x765980 <slap_sl_mfuncs>, oh_counters = 0x7fc954002240, oh_log_prefix = "conn=1003 op=1", '\000' <repeats 241 times>}, ob_controls = { 0x0 <repeats 32 times>}} op = 0x7fc9626447f0 be = {bd_info = 0x760de0 <slap_binfo>, bd_self = 0x1b72470, be_ctrls = '\000' <repeats 15 times>, "\001", '\000' <repeats 16 times>, "\001", be_flags = 131328, 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 = 0x1b72670, be_nsuffix = 0x1b726c0, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_schemandn = {bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 9, bv_val = 0x1b72610 "cn=config"}, be_rootndn = {bv_len = 9, bv_val = 0x1b72630 "cn=config"}, be_rootpw = {bv_len = 8, bv_val = 0x1b72930 "D/nFIIJ7"}, 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 = 0x1c6e000, be_dfltaccess = ACL_NONE, be_extra_anlist = 0x0, be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x0, be_pending_csn_list = 0x1b58ff0, be_pcl_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __elision = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, be_syncinfo = 0x0, be_pb = 0x0, be_cf_ocs = 0x0, be_private = 0x766680 <cfBackInfo>, be_next = {stqe_next = 0x0}} rc = 0 #2 0x00007fc967987ec3 in ldap_int_thread_pool_wrapper (xpool=0x1b4e640) at tpool.c:958 pq = 0x1b4e640 pool = 0x1b4e550 task = 0x7fc954112e30 work_list = 0x1b4e6b0 ctx = {ltu_pq = 0x1b4e640, ltu_id = 140502915897088, ltu_key = {{ltk_key = 0x43f901 <conn_counter_init>, ltk_data = 0x7fc954002240, ltk_free = 0x43f753 <conn_counter_destroy>}, {ltk_key = 0x4b3ff5 <slap_sl_mem_init>, ltk_data = 0x7fc954002350, ltk_free = 0x4b3e1a <slap_sl_mem_destroy>}, {ltk_key = 0x45a859 <slap_op_free>, ltk_data = 0x7fc954002eb0, ltk_free = 0x45a7ac <slap_op_q_destroy>}, {ltk_key = 0x0, ltk_data = 0x7fc95410bff0, ltk_free = 0x0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0x0} <repeats 28 times>}} kctx = 0x0 i = 32 keyslot = 837 hash = 1269620549 pool_lock = 0 freeme = 0 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #3 0x00007fc965e5f484 in start_thread () from /lib64/libpthread.so.0 No symbol table info available. #4 0x00007fc965b9da4d in clone () from /lib64/libc.so.6 No symbol table info available.

1 0

Re: (ITS#8142) back-ldap transparent reconnecting is not so transparent
by hyc＠symas.com 21 May '15

21 May '15

hyc(a)symas.com wrote: > ebackes(a)symas.com wrote: >> Full_Name: Emily Backes >> Version: 2.4 >> OS: >> URL: >> Submission from: (NULL) (50.113.67.84) >> >> >> Currently, back-ldap stores credentials in the outbound connection >> structure. When that disappears, e.g. from idle-timeout, conn-ttl, >> network lossage, AD trouble, etc., the connection becomes unbound and >> AD returns err=1 (Operations error), which isn't enougfofor back-ldap >> to treat it as LDAP_UNAVAILABLE. >> >> Howard reports this is working-as-designed, even if the design is bad. >> Several ITS filings are still open about this problem; 5110, 6571, and >> 7464 are all related. #5110 looks unrelated actually. >> At a minimum, we should drop the client connection if we can't keep >> the session stable. > > This is not as simple as it sounds. In particular, back-ldap may be part of a > larger glued tree of backends. A failure to search in the back-ldap context > should not prevent the rest of the glued tree from being searched, and it > should not drop the client connection. > Fixed now in master. -- -- 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#8129) ignored config variable autocommit for back-sql
by hyc＠symas.com 21 May '15

21 May '15

daniel.chobe(a)dimensiondata.com wrote: > Full_Name: Daniel Chobe > Version: 2.4.40 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (217.111.74.244) > > > This bug is related to ITS#6613. In this bug a new configvariable named > autocommit was introduced. But the flagmask in config.c was wrong, so setting > this config variable has no influence to the behavior of the slapd. > > The Patch is very simply replace SQL_AUTOCOMMIT with BSQL_AUTOCOMMIT. Thanks for the report, fixed in git master. > > > diff -rupN 1/servers/slapd/back-sql/config.c 2/servers/slapd/back-sql/config.c > --- 1/servers/slapd/back-sql/config.c 2013-11-15 04:31:27.000000000 +0100 > +++ 2/servers/slapd/back-sql/config.c 2015-05-05 14:51:43.161310554 +0200 > @@ -210,7 +210,7 @@ static ConfigTable sqlcfg[] = { > "DESC 'Quoting char of the aliasing keyword' " > "SYNTAX OMsDirectoryString SINGLE-VALUE )", NULL, NULL }, > { "autocommit", "yes|no", 2, 2, 0, > - ARG_ON_OFF|ARG_MAGIC|SQL_TOCOCOMMIT, (void *)sql_cf_gen, > + ARG_ON_OFF|ARG_MAGIC|BSQL_AUTOCOMMIT, (void *)sql_cf_gen, > "( OLcfgDbAt:6.45 NAME 'olcSqlAutocommit' " > "SYNTAX OMsBoolean SINGLE-VALUE )", NULL, NULL }, > { NULL, NULL, 0, 0, 0, ARG_IGNORED, > > -- -- 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#8150) slapcat cn=config produces LDIF that will not re-load
by hyc＠symas.com 21 May '15

21 May '15

Ryan Tandy wrote: > Does the following patch make sense? > > ftp://ftp.openldap.org/incoming/20150520_rtandy_ITS-8150-let-check_name_ind… Looks fine to me. Pushing to master. -- -- 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#8150) slapcat cn=config produces LDIF that will not re-load
by ryan＠nardis.ca 21 May '15

21 May '15

Does the following patch make sense? ftp://ftp.openldap.org/incoming/20150520_rtandy_ITS-8150-let-check_name_ind…

1 0

Re: (ITS#8150) slapcat cn=config produces LDIF that will not re-load
by andrew.findlay＠skills-1st.co.uk 20 May '15

20 May '15

On Wed, May 20, 2015 at 11:57:13AM -0700, Ryan Tandy wrote: > It does if you use an initial LDIF like the one from ITS#7016: > > $ mkdir cf.d > $ slapadd -Fcf.d -n0 > dn: cn=config > objectClass: olcGlobal > > dn: olcDatabase=frontend,cn=config > objectClass: olcDatabaseConfig > objectClass: olcFrontendConfig Good point: that suggests an incomplete fix for ITS#7106 rather than a problem in slapcat. Andrew -- ----------------------------------------------------------------------- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/ +44 1628 782565 | -----------------------------------------------------------------------

1 0

Re: (ITS#8150) slapcat cn=config produces LDIF that will not re-load
by ryan＠nardis.ca 20 May '15

20 May '15

On Wed, May 20, 2015 at 06:40:36PM +0000, hyc(a)symas.com wrote: >Unable to reproduce. It does if you use an initial LDIF like the one from ITS#7016: $ mkdir cf.d $ slapadd -Fcf.d -n0 dn: cn=config objectClass: olcGlobal dn: olcDatabase=frontend,cn=config objectClass: olcDatabaseConfig objectClass: olcFrontendConfig ^D $ slapcat -Fcf.d -n0 -l cf.ldif $ rm -r cf.d/* $ slapadd -Fcf.d -n0 -l cf.ldif slapadd: dn="olcDatabase={-1}frontend,cn=config" (line=591): (64) value of single-valued naming attribute 'olcDatabase' conflicts with value present in entry _#################### 100.00% eta none elapsed none fast! Closing DB... (I ran into this myself a while back but forgot to report it.)

1 0

Re: (ITS#8150) slapcat cn=config produces LDIF that will not re-load
by hyc＠symas.com 20 May '15

20 May '15

andrew.findlay(a)skills-1st.co.uk wrote: > Full_Name: Andrew Findlay > Version: 2.4.40 > OS: CentOS 7 > URL: > Submission from: (NULL) (2001:8b0:8d0:f7e1:a136:6cef:11df:9726) > > > When using cn=config it is sometimes necessary to extract the whole config to an > LDIF file, edit it and re-load into an empty directory. Therefore I would expect > the null-edit case to work for any system: > > slapcat -F .../config -n 0 -o ldif-wrap=no % e extracted.ldif > rm -rf .../config > mkdir .../config > slapadd -F .../config -n 0 -l extracted.ldif > > What I actually get is an error message: > slapadd: dn="olcDatabase={-1}frontend,cn=config" (line=250): (64) value of > single-valued naming attribute 'olcDatabase' conflicts with value present in > entry Unable to reproduce. violino:~/OD/o24/tests> mkdir testrun/slapd.d violino:~/OD/o24/tests> ../servers/slapd/slapd -Tc -f testrun/slapd.1.conf -F testrun/slapd.d -n0 > cf1.ldif violino:~/OD/o24/tests> ls testrun/slapd.d cn=config cn=config.ldif violino:~/OD/o24/tests> rm -rf testrun/slapd.d/* violino:~/OD/o24/tests> ../servers/slapd/slapd -Ta -F testrun/slapd.d -n0 -l cf1.ldif _#################### 100.00% eta none elapsed none fast! Closing DB... -- -- 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#8150) slapcat cn=config produces LDIF that will not re-load
by andrew.findlay＠skills-1st.co.uk 20 May '15

20 May '15

Full_Name: Andrew Findlay Version: 2.4.40 OS: CentOS 7 URL: Submission from: (NULL) (2001:8b0:8d0:f7e1:a136:6cef:11df:9726) When using cn=config it is sometimes necessary to extract the whole config to an LDIF file, edit it and re-load into an empty directory. Therefore I would expect the null-edit case to work for any system: slapcat -F .../config -n 0 -o ldif-wrap=no % e extracted.ldif rm -rf .../config mkdir .../config slapadd -F .../config -n 0 -l extracted.ldif What I actually get is an error message: slapadd: dn="olcDatabase={-1}frontend,cn=config" (line=250): (64) value of single-valued naming attribute 'olcDatabase' conflicts with value present in entry The problem is the frontend database entry: dn: olcDatabase={-1}frontend,cn=config objectClass: olcDatabaseConfig objectClass: olcFrontendConfig olcDatabase: frontend olcAccess: {0}to * by * read structuralObjectClass: olcDatabaseConfig entryUUID: 35adc8f6-9363-1034-85ee-896d5ca46112 creatorsName: cn=config createTimestamp: 20150520174137Z entryCSN: 20150520174137.558106Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20150520174137Z %SpSpecifically, the '{-1}' in the dn should either be omitted or should also be present on the olcDatabase attribute in the entry itself. The problem is in the behaviour of slapcat, but may be related to the fix for ITS#7016 Andrew

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