openldap-bugs January 2008

openldap-bugs@openldap.org

36 participants
144 discussions

(ITS#5310) ppolicy
by khxie＠directv.com 07 Jan '08

07 Jan '08

Full_Name: Kevin Xie Version: 2.3.39 OS: RHEL 4 update 3 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (147.21.16.3) I am testing ppolicy on OpenLDAP 2.3.39 and 2.3.38. When user password expired, LDAP forced user to change password using "passwd", it bypassed all the ppolicy settings, like, PwdMinLength, PwdInHistory. Is there a way to force "passwd" to check LDAP ppolicy like "ldappasswd" does? Is it because "passwd" and "ldappasswd" using different encryption methods? I've uploaded ppolicy and slapd.conf in khxie_ppolicy.txt. I've google searched the issue and didn't find any anwser. Thanks for your help. Kevin Xie

1 0

Re: (ITS#5309) ldap_pvt_thread_pool_setkey_x() addition
by h.b.furuseth＠usit.uio.no 07 Jan '08

07 Jan '08

Pierangelo Masarati writes: > Would it make any sense, at this point, to simply change the API of > setkey(), eliminating that spurious setkey_x()? I think setkey() is more readable than setkey_x(). If anything, it already has too many arguments to be very readable. -- Regards, Hallvard

1 0

Re: (ITS#5309) ldap_pvt_thread_pool_setkey_x() addition
by ando＠sys-net.it 07 Jan '08

07 Jan '08

h.b.furuseth(a)usit.uio.no wrote: > HEAD has gotten a new function ldap_pvt_thread_pool_setkey_x() replacing > ldap_pvt_thread_pool_setkey() (now a macro), but the change is incomplete. > Fixing thr_stub & thr_debug, they still define ldap_pvt_thread_pool_setkey. > > Related: overlays/memberof.c, pool_<getkey and setkey_x> should receive > a pointer to a void variable, not a (void **) cast of the address of a > non-void pointer variable. Otherwise a void* pointer gets stored in a > non-void* pointer instead of being converted to void. > > I'll combine another of memberof's getkey() followed by setkey() into > setkey_x() while I'm at it. > > Also making passwd.c:slap_passwd_check() and backend.c:be_rootdn_bind() > reentrant: Use setkey_x()/setkey() to push/pop the key=slap_sasl_bind > value instead of setkey()/setkey() to set/reset it. Would it make any sense, at this point, to simply change the API of setkey(), eliminating that spurious setkey_x()? p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. 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#5309) ldap_pvt_thread_pool_setkey_x() addition
by h.b.furuseth＠usit.uio.no 07 Jan '08

07 Jan '08

Full_Name: Hallvard B Furuseth Version: HEAD OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard HEAD has gotten a new function ldap_pvt_thread_pool_setkey_x() replacing ldap_pvt_thread_pool_setkey() (now a macro), but the change is incomplete. Fixing thr_stub & thr_debug, they still define ldap_pvt_thread_pool_setkey. Related: overlays/memberof.c, pool_<getkey and setkey_x> should receive a pointer to a void variable, not a (void **) cast of the address of a non-void pointer variable. Otherwise a void* pointer gets stored in a non-void* pointer instead of being converted to void. I'll combine another of memberof's getkey() followed by setkey() into setkey_x() while I'm at it. Also making passwd.c:slap_passwd_check() and backend.c:be_rootdn_bind() reentrant: Use setkey_x()/setkey() to push/pop the key=slap_sasl_bind value instead of setkey()/setkey() to set/reset it.

1 0

(ITS#5308) test034-translucent crashes with back-ldif
by h.b.furuseth＠usit.uio.no 07 Jan '08

07 Jan '08

Full_Name: Hallvard B Furuseth Version: HEAD OS: Linux URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard "./run -b ldif test034-translucent" crashes in str2entry2() at: entry.c:298: if( ad_prev->ad_type->sat_equality && because ad_prev == NULL - which got through due to this statement: entry.c:278: if (( ad_prev && ad != ad_prev ) || ( i == lines )) { (gdb) backtrace full #0 0x080778b9 in str2entry2 (s=0x0, checkvals=1) at entry.c:298 j = 0 k = 0 rc = 0 e = (Entry *) 0x1bca12d4 type = (struct berval *) 0x1bc4af40 vals = (struct berval *) 0x1bc4af50 nvals = (struct berval *) 0x1bc4af60 freeval = 0x1bc4af70 "" ad = (AttributeDescription *) 0x1bc4b100 ad_prev = (AttributeDescription *) 0x0 text = 0x819642b "attribute type undefined" next = 0x1bc4af0d "" attr_cnt = 0 i = 0 lines = 0 ahead = {a_desc = 0x0, a_vals = 0x0, a_nvals = 0x8189305, a_numvals = 465874688, a_flags = 477302072, a_next = 0x1bcabc2c, a_comp_data = 0x0} atail = (Attribute *) 0x1bcabc2c #1 0x08076c28 in str2entry (s=0x1bc4af00 "dn") at entry.c:100 No locals. #2 0x0810084a in get_entry_for_fd (fd=12, pdn=0x1c730de4, pndn=0x1c730ddc) at ldif.c:339 entry = 0x1bc4af00 "dn" ldentry = (Entry *) 0x0 #3 0x08100a99 in get_entry (op=0x1bb0bc30, base_path=0x1bc315b0) at ldif.c:379 path = {bv_len = 100, bv_val = 0x1bc4adc8 "/usit/bombur/site/hbf/scratch/ldap/ol/HEAD/tests/testrun/db.2.a/o=translucent/ou=users/uid=fred.ldif"} pdn = {bv_len = 22, bv_val = 0x1bd2c185 "ou=users,o=translucent"} pndn = {bv_len = 22, bv_val = 0x1bd2c1e5 "ou=users,o=translucent"} fd = 12 #4 0x081018f1 in ldif_back_referrals (op=0x1bb0bc30, rs=0x1c731138) at ldif.c:719 li = (struct ldif_info *) 0x1bc315b0 entry = (Entry *) 0x1c730fc8 rc = 0 #5 0x080e1c31 in overlay_op_walk (op=0x1bb0bc30, rs=0x1c731138, which=op_aux_chk_referrals, oi=0x1bc31e80, on=0x0) at backover.c:653 func = (BI_op_bind **) 0x81dc15c rc = 32768 #6 0x080e1de6 in over_op_func (op=0x1bb0bc30, rs=0x1c731138, which=op_aux_chk_referrals) at backover.c:705 oi = (slap_overinfo *) 0x1bc31e80 on = (slap_overinst *) 0x1bc31fb0 be = (BackendDB *) 0x1bc31470 db = {bd_info = 0x81dc130, be_ctrls = '\0' <repeats 18 times>, "\001", '\0' <repeats 13 times>, "\001", be_flags = 259, 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 = 0x1bc31a18, be_nsuffix = 0x1bc31a58, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_schemandn = {bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 13, bv_val = 0x1bc31cf8 "o=translucent"}, be_rootndn = {bv_len = 13, bv_val = 0x1bc31d80 "o=translucent"}, be_rootpw = {bv_len = 6, bv_val = 0x1bc31e00 "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 = 0x1bb23530, be_pcl_mutex = { wrapped = {__m_reserved = 0, __m_count = 0, __m_owner = 0x0, __m_kind = 2, __m_lock = {__status = 0, __spinlock = 0}}, usage = { magic = ldap_debug_magic, self = 3829197487, mem = {ptr = 0x0, num = 0}, state = ldap_debug_state_inited}, owner = 4294967295}, be_pcl_mutexp = 0x1bc31538, be_syncinfo = 0x0, be_pb = 0x0, be_cf_ocs = 0x81deca0, be_private = 0x1bc315b0, be_next = {stqe_next = 0x0}} cb = {sc_next = 0x0, sc_response = 0x80e10c3 <over_back_response>, sc_cleanup = 0, sc_private = 0x1bc31e80} rc = 32768 __PRETTY_FUNCTION__ = "over_op_func" #7 0x080e1fbe in over_aux_chk_referrals (op=0x1bb0bc30, rs=0x1c731138) at backover.c:787 No locals. #8 0x0807c586 in backend_check_referrals (op=0x1bb0bc30, rs=0x1c731138) at backend.c:1301 No locals. #9 0x0808b143 in fe_op_modrdn (op=0x1bb0bc30, rs=0x1c731138) at modrdn.c:274 newSuperior_be = (Backend *) 0x0 pdn = {bv_len = 0, bv_val = 0x0} op_be = (BackendDB *) 0x1bc31470 bd = (BackendDB *) 0x81e3aa0 #10 0x0808acb3 in do_modrdn (op=0x1bb0bc30, rs=0x1c731138) at modrdn.c:186 dn = {bv_len = 31, bv_val = 0x1bc4abe7 "uid=fred,ou=users,o=translucent"} newrdn = {bv_len = 11, bv_val = 0x1bc4ac08 "uid=someguy"} newSuperior = {bv_len = 0, bv_val = 0x0} deloldrdn = 0 pnewSuperior = {bv_len = 0, bv_val = 0x0} nnewSuperior = {bv_len = 0, bv_val = 0x0} length = 0 #11 0x0806b483 in connection_operation (ctx=0x1c731214, arg_v=0x1bb0bc30) at connection.c:1083 rc = 80 op = (Operation *) 0x1bb0bc30 rs = {sr_type = REP_RESULT, sr_tag = 0, sr_msgid = 0, sr_err = 0, sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0, sr_ctrls = 0x0, sr_un = { sru_sasl = {r_sasldata = 0x0}, sru_extended = {r_rspoid = 0x0, r_rspdata = 0x0}, sru_search = {r_entry = 0x0, r_attr_flags = 0, r_operational_attrs = 0x0, r_attrs = 0x0, r_nentries = 0, r_v2ref = 0x0}}, sr_flags = 0} tag = 108 opidx = SLAP_OP_MODRDN conn = (Connection *) 0x1be539e0 memctx = (void *) 0x1bb0c048 memctx_null = (void *) 0x0 memsiz = 1048576 __PRETTY_FUNCTION__ = "connection_operation" #12 0x0806b943 in connection_read_thread (ctx=0x1c731214, argv=0x9) at connection.c:1210 rc = 0 cri = {op = 0x1bb0bc30, func = 0, arg = 0x0, ctx = 0x1c731214, nullop = 0} s = 9 #13 0x08144a1c in ldap_int_thread_pool_wrapper (xpool=0x1bb50e30) at tpool.c:625 pool = (struct ldap_int_thread_pool_s *) 0x1bb50e30 task = (ldap_int_thread_task_t *) 0x1bb24400 ctx = {ltu_id = 477305760, ltu_key = {{ltk_key = 0x806b05d, ltk_data = 0x1bb778b0, ltk_free = 0x806aefe <conn_counter_destroy>}, { ltk_key = 0x80cb901, ltk_data = 0x1bb0c048, ltk_free = 0x80cb738 <slap_sl_mem_destroy>}, {ltk_key = 0x8082923, ltk_data = 0x0, ltk_free = 0x80828a0 <slap_op_q_destroy>}, { ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 29 times>}} kctx = (ldap_int_thread_userctx_t *) 0x0 i = 32 keyslot = 426 hash = 5776810 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #14 0x00a633cc in start_thread () from /lib/tls/libpthread.so.0 No symbol table info available. #15 0x008cb1ae in clone () from /lib/tls/libc.so.6 No symbol table info available.

1 0

Re: (ITS#5291) Client timeout dumps core
by hyc＠symas.com 06 Jan '08

06 Jan '08

daveh(a)coreng.com.au wrote: > FWIW, I back-ported the fix (1.81 in libraries/libldap/search.c) to 2.4.7, > and it works fine (both the test harness and my application). > > Many thanks. > Thanks for the followup. We'll make sure the fix is in 2.4.8. -- -- Howard Chu Chief Architect, 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#5291) Client timeout dumps core
by daveh＠coreng.com.au 06 Jan '08

06 Jan '08

FWIW, I back-ported the fix (1.81 in libraries/libldap/search.c) to 2.4.7, and it works fine (both the test harness and my application). Many thanks. -- Dave Horsfall DTM VK2KFU Ph: +61 2 9552-5509 (direct) +61 2 9552-5500 (switch) Corinthian Eng'ng P/L, Ste 54 Jones Bay Whf, 26-32 Pirrama Rd, Pyrmont 2009, AU

1 0

Crashing database
by Carlos Parada 06 Jan '08

06 Jan '08

Hi all, (First of all, sorry for this "generic" thread) I'm using the openldap 2.3.34 version (I've already used previous ones). My usage is a bit different than the usual. I have a lot of write operations - tens per second - (adds, deletes) and also a lots of reads. I use to have very often a crash in my database. I'm using the bdb backend. Sometimes it is enough to restart my server to corrupt the database (at least to not be able to restart it). In other occasions, I corrupt my database using the slapcat command, which I know it is nor recommended, but it is also not disallowed by the application (and I think it was in previous versions). That buggy behavior should not be normal. I've already search and it seems it is a common problem using the bdb, many times reported. My question is: what is really happening? Am I configuring wrongly the server, DBD parameters, or anything else? Or there is a systematic bug not solved yet ? How to solve it? Another secondary issue is the recovery. Most of the times, I'm not able to recover my database either using db_recover or slapd_db_recover. Is there any trick for a more efficient recovery. Cumprimentos, Carlos Parada

2 3

Re: (ITS#5305) Contribware: Two overlays for implementing NESTED dynamic groups
by ando＠sys-net.it 05 Jan '08

05 Jan '08

Jose, few preliminary comments: - you coded your contribution for OpenLDAP 2.3; however, since it configures as a new feature, it should be coded for OpenLDAP 2.4 (better for HEAD), as 2.3 is feature-frozen ever since. This comment may appear trivial, but right now your contribution does not compile with HEAD/re24 because of some internal API changes. - the coding style you used does not conform to that of the OpenLDAP project. Although this is usually only loosely enforced, you used things we're a bit picky about, like C++-style comments, and late declarations; if you compile with enough warnings (e.g., with gcc, with -Wall -pedantic) you'll see that in many cases functions are not returning when a return value is expected or vice-versa; incorrect formats are used for (long) integers, pointers and so. Also, I note that besides being a totally new contribution, many of the comments are already no longer aligned with the code. - according to agreed development lines, new contributions should always provide back-config support (this can be added later, if and when the rest works as expected) - with respect to the possible improvements you indicate, I think: 1) permission checking should occur along the lines of, e.g., slapo-dynlist(5), honoring dgIdentity and dgAuthz. 2) avoiding unnecessary expansion would probably be mandatory for production use 3) use back-config rather than naive in-database configuration using an ordinary database - The build instructions you provide are incorrect: you suggest to place the source in servers/slapd/overlays/, and to modify statover.c; this is a generated file, so it should never be modified. You should rather suggest to place the sources in an arbitrary directory (it could be contrib/slapd-modules/nestedAggregateAttr as soon as your contribution enters the official distribution) and build it as a run-time module. - you should rather eliminate duplicate values from result sets (much like slapo-dynlist(5) does) as they are not allowed by the definition of the "member" attribute, which has a distinguishedNameMatch EQUALITY rule. - instead of copying compare_entry(), you should rather ask to make the one in servers/slapd/compare.c non-static - since the "OR" operator in filters allows more than 2 operands, I think your filter combination strategy could be optimized by simply defining a combine_filters() function that counts the number of filter strings in the array and creates a filter like "(|(f1)(f2)(f3)...)" - in check_filter(), you compare strings; you should rather compare pointers to AttributeDescription structures. - in nestedAggregateAttrURL_search() you don't need to run str2filter() on op->ors_filterstr, since an exploded filter is already available in op->ors_filter - strings[] containing "(objectClass=<ocname>)" could be prepared once for all during config; it would save a lot of mallocs (BTW: use the slab for operation-spanning allocation). - I would recommend you do some consistent checking of return values before dereferencing pointers. - I would recommend that you either remove or turn into useful standard debugging the plethora of non-standard messages you added. Use LDAP_DEBUG_ARGS to mark entering/exiting functions (and logging useful args); use LDAP_DEBUG_TRACE to trace operations; use slap_loglevel_get() to register friendly names for specific log subsystems (you'll get back the number to compare with ldap_debug). - with respect to the OID for the test schema items, you'll get an OID arc in the experimental OID namespace of the OpenLDAP project as soon as your contribution is incorporated. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. 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#5305) Contribware: Two overlays for implementing NESTED dynamic groups
by ando＠sys-net.it 05 Jan '08

05 Jan '08

josemarcodelarosa(a)gmail.com wrote: > Yes, you are completely right. The only reason I can think of using the > DN version is because you are forced by your schema (attribute types for the > expansion source attribute differ). I emphasize that the implementation of > both is quite different. The DN version uses recursivity while the URL > version relies in slapd's search-reply mechanism. I just added the first one > as an example. > > URL version is much more powerful and more elegant. You suggested > subGroupURL: ldap:///<dn>??base, but even subGroupURL: ldap:///<dn> works ok > (if I remember right). According to Section 3 of RFC 4516, if <scope> is omitted, a scope of "base" is assumed. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. 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

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs January 2008