openldap-bugs May 2014

openldap-bugs@openldap.org

26 participants
75 discussions

Re: (ITS#7844) LMDB Delete Cursor inconsistencies
by dw＠hmmz.org 13 May '14

13 May '14

This sounds very much like a known regression in mdb.master in the past few months. If you are still affected, please retest against LMDB 0.9.11 which at least was not affected by the regression. David

1 0

Re: (ITS#7853) Improve safety of mdb_env_close
by dw＠botanicus.net 13 May '14

13 May '14

It's worth mentioning that this is not a theoretical issue, I've already hit it while writing unit tests.

1 0

(ITS#7853) Improve safety of mdb_env_close
by dw＠botanicus.net 13 May '14

13 May '14

Full_Name: David Wilson Version: LMDB 0.9.11 OS: URL: https://raw.githubusercontent.com/dw/py-lmdb/master/misc/readers_mrb_env.pa… Submission from: (NULL) (178.238.153.20) Currently if a user (wilfully or accidentally, say, through composition of third party libs) opens the same LMDB environment twice within a process, and maintains active read transactions at the time one mdb_env_close() is called, all reader slots will be deallocated in all environments due to the logic around line 4253 that unconditionally clears reader slots based on PID. I'd like to avoid this in py-lmdb, and seems there are a few alternatives to fix it: 1) Tell users not to do that (doc fix, nobody reads docs) 2) Externally maintain a set of (st_dev, st_ino) keys representing already opened environments, and check any attempt to open an environment against this list, failing if data.mdb's key already appears. 3) Disable the mdb_env_close() cleanup loop when MDB_NOTLS is enabled. Since no reader slot will ever exist in TLS in this mode, the existing mdb_env_close() doc "All transactions, databases, and cursors must already be closed before calling this function." ensures no readers exist at close time, and the loop need not run. 4) Modify lock.mdb to include MDB_env* address within the process, and update mdb_env_close() to invalidate only readers associated with the environment being closed. I dislike using the MDB_env* as an opaque publicly visible cookie, but perhaps storing this field might be reused for other things in future. Option 3 lets the user wilfully mix py-lmdb Environment objects within the process, since py-lmdb always enables NOTLS, but it does not fix the case where the user is integrating a Python application with a C library with some opaque interface, and both the application and the library independently have need to access the environment. This kind of scenario regularly crops up in huge software projects, the user may not even be aware the library uses LMDB internally. In that case, the user is again exposed to having their reader slots silently become deallocated through no fault of their own. Option 4 is the least aesthetic, but has all the benefits of option 3 in addition to preventing the "accidental integration" scenario. I've attached a patch for it (against 0.9.11), although I completely understand if it does not get applied. :) One alternative would be instead of using MDB_env* address, using a monotonically increasing counter based on a static global, say, "mrb_token", but this might break in the case two copies of LMDB were somehow linked in the application. (It's easy to argue the user is an idiot in this case ;) David

1 0

Re: (ITS#7852) problems in memberof overlay
by quanah＠zimbra.com 12 May '14

12 May '14

--On May 12, 2014 at 10:20:24 AM +0000 efbt(a)hotmail.com wrote: > Full_Name: jeff.gao > Version: 2.4.23 The ITS system is for reporting software bugs, not for asking usage questions. Please redirect your question to the openldap-technical(a)openldap.org list. I would note that the OpenLDAP 2.4.23 build shipped by RHEL is utterly broken. I strongly advise you obtain a working build. If you are unable to build OpenLDAP yourself, you can obtain a working build from Symas or the LTB project. This ITS will be closed. --Quanah -- Quanah Gibson-Mount Server Architect Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#7852) problems in memberof overlay
by efbt＠hotmail.com 12 May '14

12 May '14

Full_Name: jeff.gao Version: 2.4.23 OS: centos URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (114.242.123.100) hi. I configured the function of 'memberof overlay' these days, but At first I used the methods on the webpage of http://www.openldap.org/doc/admin24/overlays.html, I add the codes of "overlay memeberof" in the file of slapd.conf,then I started the slapd service, the system give me an error "overlay "memberof" not found" . second,I googled the internet and found an article on this webpage:http://www.redmine.org/projects/redmine/wiki/RedmineLDAP,so I create two LDIF files as follow: the first file : dn: cn=module,cn=config objectClass: olcModuleList cn: module olcModulePath: /usr/lib/ldap olcModuleLoad: memberof the second file: dn: olcOverlay=memberof,olcDatabase={1}hdb,cn=config objectClass: olcMemberOf objectClass: olcOverlayConfig objectClass: olcConfig objectClass: top olcOverlay: memberof olcMemberOfDangling: ignore olcMemberOfRefInt: TRUE olcMemberOfGroupOC: groupOfNames olcMemberOfMemberAD: member olcMemberOfMemberOfAD: memberOf after I entered the command "ldapadd -x -D 'cn=Manager,dc=example,dc=com' -W -f 1.ldif",the system give an error:"ldap_add: Insufficient access (50)" please help me ,thanks.

1 0

Re: (ITS#7851) [PATCH] buffer overrun in password checkers with malformed hash
by ryan＠nardis.ca 11 May '14

11 May '14

Sorry, I missed a line from the patch. Corrected one: ftp://ftp.openldap.org/incoming/rtandy_20140511_fix-passwd-b64-buffer_v2.pa…

1 0

(ITS#7851) [PATCH] buffer overrun in password checkers with malformed hash
by ryan＠nardis.ca 11 May '14

11 May '14

Full_Name: Ryan Tandy Version: master, commit 141f1680 OS: Ubuntu 14.04 URL: ftp://ftp.openldap.org/incoming/rtandy_20140511_fix-passwd-b64-buffer.patch Submission from: (NULL) (24.68.121.206) The password checkers call lutil_b64_pton like this: rc = lutil_b64_pton(passwd->bv_val, orig_pass, passwd->bv_len); However, the size of orig_pass is actually only 3/4 of passwd->bv_len. Normally this isn't a problem; however, if the length of the password hash is not a multiple of 4, then LUTIL_BASE64_DECODE_LEN rounds down, orig_pass gets a shorter buffer allocated than is actually needed, and it's possible for lutil_b64_pton to write past its end. (How can that happen? An admin could mess up copy-pasting from slappasswd to userPassword/olcRootPW, as could a user with write access to their own userPassword who decided to set it manually.) Example: $ slappasswd -s secret -h '{SSHA}' {SSHA}86ks4vJqfruLKer9skuEpTmgPxcaqSLe If we lose the last character ('e') and try to authenticate against the length 31 string, clang's AddressSanitizer notices: ==15335==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x603000049736 at pc 0xef0720 bp 0x7fa9b38d1c10 sp 0x7fa9b38d1c08 WRITE of size 1 at 0x603000049736 thread T2 #0 0xef071f in lutil_b64_pton (libraries/liblutil/base64.c:225) #1 0xe9547c in chk_ssha1 (libraries/liblutil/passwd.c:508) #2 0xe90a09 in lutil_passwd (libraries/liblutil/passwd.c:327) #3 0x7d5e1c in slap_passwd_check (servers/slapd/passwd.c:529) [snip ...] 0x603000049736 is located 0 bytes to the right of 22-byte region [0x603000049720,0x603000049736) allocated by thread T2 here: #0 0x43c9a4 in malloc (/opt/openldap/libexec/slapd+0x43c9a4) #1 0x112903f in ber_memalloc_x (libraries/liblber/memory.c:228) #2 0x1129396 in ber_memalloc (libraries/liblber/memory.c:244) #3 0xe952ea in chk_ssha1 (libraries/liblutil/passwd.c:503) #4 0xe90a09 in lutil_passwd (libraries/liblutil/passwd.c:327) #5 0x7d5e1c in slap_passwd_check (servers/slapd/passwd.c:529) [snip...] (Built with ./configure CC=clang CFLAGS="-O0 -g -fsanitize=address") Patch in URL. (Apparently the apr1 passwd module has CRLF endings; sorry for the noisy diff.) BTW, I noticed in the same routines that orig_pass is allocated with + 1 to the required length, as if it were to be null-terminated, but that's never done. Is that intentional? (AFAICS ber_memalloc doesn't zero memory, maybe I'm wrong.) thanks, Ryan

1 0

Re: (ITS#7850) slapd crashes on modrdn to an attr with no equality matching rule
by ryan＠nardis.ca 09 May '14

09 May '14

On Fri, May 9, 2014 at 11:33 AM, Howard Chu <hyc(a)symas.com> wrote: > Thanks for the report. Should be fixed now in git master, please test. $ ldapmodrdn -x -D cn=root,dc=example,dc=com -W 'cn=Ryan Tandy,dc=example,dc=com' 'jpegPhoto=test' Enter LDAP Password: Rename Result: Naming violation (64) Additional info: naming attribute has no equality matching rule Confirmed fixed.

1 0

Re: (ITS#7850) slapd crashes on modrdn to an attr with no equality matching rule
by hyc＠symas.com 09 May '14

09 May '14

ryan(a)nardis.ca wrote: > Full_Name: Ryan Tandy > Version: HEAD > OS: Ubuntu 14.04 > URL: > Submission from: (NULL) (142.32.208.226) > > > Debian bug report: http://bugs.debian.org/666515 > > Confirmed on master (at commit fcdd3a06) and RE24 (at commit 1253d7c1). Thanks for the report. Should be fixed now in git master, please test. > > ldapadd or slapadd of an entry with a naming attribute such as 'audio' or > 'jpegPhoto' is rejected with a reasonable error message: > > $ slapadd > dn: jpegPhoto=test,dc=example,dc=com > objectClass: inetOrgPerson > > slapadd: dn="jpegPhoto=test,dc=example,dc=com" (line=1): (64) naming attribute > 'jpegPhoto' has no equality matching rule > > However, creating an entry with a valid DN and using ldapmodrdn to request a > change of the naming attr to 'jpegPhoto' crashes slapd: > > $ slapadd > dn: cn=Ryan Tandy,dc=example,dc=com > objectClass: inetOrgPerson > sn: Tandy > jpegPhoto: test > > $ [start slapd...] > $ ldapmodrdn -x -D cn=root,dc=example,dc=com -W 'cn=Ryan > Tandy,dc=example,dc=com' 'jpegPhoto=test' > Enter LDAP Password: > ldap_result: Can't contact LDAP server (-1) > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 0x7ffd81a60700 (LWP 9095)] > 0x00000000004667f3 in slap_modrdn2mods (op=0x7ffd740026b0, rs=0x7ffd81a5faf0) at > modrdn.c:448 > 448 if( desc->ad_type->sat_equality->smr_normalize) { > (gdb) bt full > #0 0x00000000004667f3 in slap_modrdn2mods (op=0x7ffd740026b0, > rs=0x7ffd81a5faf0) at modrdn.c:448 > desc = 0x9add80 > mod_tmp = 0x7ffd74002670 > a_cnt = 0 > d_cnt = 32765 > old_rdn = 0x0 > new_rdn = 0x7ffd74003090 > __PRETTY_FUNCTION__ = "slap_modrdn2mods" > #1 0x0000000000465688 in do_modrdn (op=0x7ffd740026b0, rs=0x7ffd81a5faf0) at > modrdn.c:179 > dn = {bv_len = 31, bv_val = 0x7ffd74102c77 "cn=Ryan > Tandy,dc=example,dc=com"} > newrdn = {bv_len = 14, bv_val = 0x7ffd74102c98 "jpegPhoto=test"} > 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 > #2 0x000000000044029f in connection_operation (ctx=0x7ffd81a5fc40, > arg_v=0x7ffd740026b0) at connection.c:1134 > rc = 80 > cancel = 0 > op = 0x7ffd740026b0 > 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_search = {r_entry = 0x0, r_attr_flags = > 0, r_operational_attrs = 0x0, r_attrs = 0x0, > r_nentries = 0, r_v2ref = 0x0}, sru_sasl = {r_sasldata = 0x0}, > sru_extended = {r_rspoid = 0x0, r_rspdata = 0x0}}, > sr_flags = 0} > tag = 108 > opidx = SLAP_OP_MODRDN > conn = 0x7ffff7e6ae90 > memctx = 0x7ffd74002bf0 > memctx_null = 0x0 > memsiz = 1048576 > __PRETTY_FUNCTION__ = "connection_operation" > #3 0x00000000004408f8 in connection_read_thread (ctx=0x7ffd81a5fc40, argv=0x10) > at connection.c:1270 > rc = 0 > cri = {op = 0x7ffd740026b0, func = 0x0, arg = 0x0, ctx = 0x7ffd81a5fc40, > nullop = 0} > s = 16 > #4 0x00007ffff7b89e5e in ldap_int_thread_pool_wrapper (xpool=0x7fa480) at > tpool.c:945 > pq = 0x7fa480 > pool = 0x7fa370 > task = 0x7ffd7c0008c0 > work_list = 0x7fa4f0 > ctx = {ltu_pq = 0x7fa480, ltu_id = 140726778595072, ltu_key = {{ltk_key > = 0x43fd34 <conn_counter_init>, > ltk_data = 0x7ffd74002ae0, ltk_free = 0x43fb86 > <conn_counter_destroy>}, {ltk_key = 0x4b9a08 <slap_sl_mem_init>, > ltk_data = 0x7ffd74002bf0, ltk_free = 0x4b982d > <slap_sl_mem_destroy>}, {ltk_key = 0x45c06b <slap_op_free>, > ltk_data = 0x0, ltk_free = 0x45bfbe <slap_op_q_destroy>}, {ltk_key > = 0x0, ltk_data = 0x0, > ltk_free = 0x0} <repeats 23 times>, {ltk_key = 0x0, ltk_data = > 0xe81b289de6cb1252, ltk_free = 0x80}, {ltk_key = 0x0, > ltk_data = 0x0, ltk_free = 0x0}, {ltk_key = 0x0, ltk_data = 0x0, > ltk_free = 0x0}, {ltk_key = 0x0, ltk_data = 0x0, > ltk_free = 0x0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0x0}, > {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0x0}}} > kctx = 0x0 > i = 32 > keyslot = 586 > hash = 2858034762 > pool_lock = 0 > freeme = 0 > __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" > #5 0x00007ffff5dbf062 in start_thread (arg=0x7ffd81a60700) at > pthread_create.c:312 > __res = <optimized out> > pd = 0x7ffd81a60700 > now = <optimized out> > unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140726778595072, > 1720423256181903954, 1, 140737354125408, 0, 140726778595072, > -1721737773892038062, -1720445005621816750}, mask_was_saved = > 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = { > prev = 0x0, cleanup = 0x0, canceltype = 0}}} > not_first_call = <optimized out> > pagesize_m1 = <optimized out> > sp = <optimized out> > freesize = <optimized out> > __PRETTY_FUNCTION__ = "start_thread" > #6 0x00007ffff5af2bfd in clone () at > ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 > No locals. > > The problem is a dereference of the missing equality rule: > > (gdb) p desc->ad_type > $1 = (AttributeType *) 0x83ec70 > (gdb) p desc->ad_type->sat_equality > $2 = (MatchingRule *) 0x0 > > -- -- 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#6890) SHA2 Password Hashing not working
by ryan＠nardis.ca 09 May '14

09 May '14

Hi, This is fixed by ITS#7284, included since 2.4.32. slappasswd -o module-load=pw-sha2 -h '{SHA512}' thanks, Ryan

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs May 2014