- openldap-bugs - openldap.org

[Bug 9135] mdb index corruption during legitimate delete
by openldap-its＠openldap.org 13 Mar '20

13 Mar '20

https://bugs.openldap.org/show_bug.cgi?id=9135 quanah(a)openldap.org changed: What |Removed |Added ---------------------------------------------------------------------------- Component|slapd |backends CC| |openldap-bugs(a)openldap.org -- You are receiving this mail because: You are watching someone on the CC list of the bug.

1 0

[Bug 9136] mdb index degradation failure
by openldap-its＠openldap.org 13 Mar '20

13 Mar '20

https://bugs.openldap.org/show_bug.cgi?id=9136 quanah(a)openldap.org changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |openldap-bugs(a)openldap.org Component|slapd |backends -- You are receiving this mail because: You are watching someone on the CC list of the bug.

1 0

[Bug 9125] [regression] back-ldap does not respect --without-tls
by openldap-its＠openldap.org 13 Mar '20

13 Mar '20

https://bugs.openldap.org/show_bug.cgi?id=9125 quanah(a)openldap.org changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |openldap-bugs(a)openldap.org Component|slapd |backends -- You are receiving this mail because: You are watching someone on the CC list of the bug.

1 0

[Bug 9099] LMDB: range delete
by openldap-its＠openldap.org 13 Mar '20

13 Mar '20

https://bugs.openldap.org/show_bug.cgi?id=9099 quanah(a)openldap.org changed: What |Removed |Added ---------------------------------------------------------------------------- Component|slapd |liblmdb CC| |openldap-bugs(a)openldap.org Product|OpenLDAP |LMDB -- You are receiving this mail because: You are watching someone on the CC list of the bug.

1 0

[Bug 9176] libldap support for TLSv1.3 Encrypted SNI
by openldap-its＠openldap.org 13 Mar '20

13 Mar '20

https://bugs.openldap.org/show_bug.cgi?id=9176 quanah(a)openldap.org changed: What |Removed |Added ---------------------------------------------------------------------------- Component|slapd |libraries CC| |openldap-bugs(a)openldap.org -- You are receiving this mail because: You are watching someone on the CC list of the bug.

1 0

[Bug 8913] Add meson build system to lmdb
by openldap-its＠openldap.org 13 Mar '20

13 Mar '20

https://bugs.openldap.org/show_bug.cgi?id=8913 quanah(a)openldap.org changed: What |Removed |Added ---------------------------------------------------------------------------- Component|slapd |liblmdb Product|OpenLDAP |LMDB CC| |openldap-bugs(a)openldap.org -- You are receiving this mail because: You are watching someone on the CC list of the bug.

1 0

[Bug 8883] add custom attribute
by openldap-its＠openldap.org 13 Mar '20

13 Mar '20

https://bugs.openldap.org/show_bug.cgi?id=8883 quanah(a)openldap.org changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|SECURITY: add custom |add custom attribute |attribute | -- You are receiving this mail because: You are watching someone on the CC list of the bug.

1 0

[Bug 8883] SECURITY: add custom attribute
by openldap-its＠openldap.org 13 Mar '20

13 Mar '20

https://bugs.openldap.org/show_bug.cgi?id=8883 quanah(a)openldap.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |VERIFIED -- You are receiving this mail because: You are watching someone on the CC list of the bug.

1 0

[Bug 8883] SECURITY: add custom attribute
by openldap-its＠openldap.org 13 Mar '20

13 Mar '20

1 0

Re: (ITS#9182) slapd crash with invalid pcache config
by ryan＠nardis.ca 11 Mar '20

11 Mar '20

On Wed, Mar 11, 2020 at 07:18:22PM +0000, Howard Chu wrote: >Fixed in git master Confirmed fixed, thanks!

1 0

Re: (ITS#9182) slapd crash with invalid pcache config
by hyc＠symas.com 11 Mar '20

11 Mar '20

ryan(a)openldap.org wrote: > Full_Name: Ryan Tandy > Version: RE24 > OS: Debian > URL: > Submission from: (NULL) (70.66.128.207) > Submitted by: ryan > > > Reported in IRC #openldap by user Dragnell, reproduced by me on current RE24. > > Configure slapd like so: > Fixed in git 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#9182) slapd crash with invalid pcache config
by ryan＠nardis.ca 11 Mar '20

11 Mar '20

==24838== Thread 3: ==24838== Invalid read of size 8 ==24838== at 0x13FCD3: backend_stopdown_one (backend.c:425) ==24838== by 0x1DF97A: pcache_db_destroy (pcache.c:4899) ==24838== by 0x19AD46: overlay_destroy_one (backover.c:1150) ==24838== by 0x124A10: config_add_internal.isra.16 (bconfig.c:5318) ==24838== by 0x125323: config_back_add (bconfig.c:5457) ==24838== by 0x13968C: fe_op_add (add.c:334) ==24838== by 0x13A49D: do_add (add.c:194) ==24838== by 0x1332BB: connection_operation (connection.c:1175) ==24838== by 0x133D52: connection_read_thread (connection.c:1311) ==24838== by 0x1F8238: ldap_int_thread_pool_wrapper.part.0 (tpool.c:696) ==24838== by 0x486BFA2: start_thread (pthread_create.c:486) ==24838== by 0x497E4CE: clone (clone.S:95) ==24838== Address 0x4ecec10 is 0 bytes inside a block of size 16 free'd ==24838== at 0x48369AB: free (vg_replace_malloc.c:530) ==24838== by 0x13FD34: backend_stopdown_one (backend.c:434) ==24838== by 0x1DF97A: pcache_db_destroy (pcache.c:4899) ==24838== by 0x19AD46: overlay_destroy_one (backover.c:1150) ==24838== by 0x124A10: config_add_internal.isra.16 (bconfig.c:5318) ==24838== by 0x125323: config_back_add (bconfig.c:5457) ==24838== by 0x13968C: fe_op_add (add.c:334) ==24838== by 0x13A49D: do_add (add.c:194) ==24838== by 0x1332BB: connection_operation (connection.c:1175) ==24838== by 0x133D52: connection_read_thread (connection.c:1311) ==24838== by 0x1F8238: ldap_int_thread_pool_wrapper.part.0 (tpool.c:696) ==24838== by 0x486BFA2: start_thread (pthread_create.c:486) ==24838== Block was alloc'd at ==24838== at 0x4837B65: calloc (vg_replace_malloc.c:752) ==24838== by 0x21FE44: ber_memcalloc_x (memory.c:283) ==24838== by 0x14DB62: ch_calloc (ch_malloc.c:104) ==24838== by 0x13F661: backend_startup_one (backend.c:200) ==24838== by 0x13F98A: backend_startup (backend.c:325) ==24838== by 0x15F920: slap_startup (init.c:219) ==24838== by 0x119D22: main (main.c:1005) ==24838== ==24838== Invalid free() / delete / delete[] / realloc() ==24838== at 0x48369AB: free (vg_replace_malloc.c:530) ==24838== by 0x13FD34: backend_stopdown_one (backend.c:434) ==24838== by 0x1DF97A: pcache_db_destroy (pcache.c:4899) ==24838== by 0x19AD46: overlay_destroy_one (backover.c:1150) ==24838== by 0x124A10: config_add_internal.isra.16 (bconfig.c:5318) ==24838== by 0x125323: config_back_add (bconfig.c:5457) ==24838== by 0x13968C: fe_op_add (add.c:334) ==24838== by 0x13A49D: do_add (add.c:194) ==24838== by 0x1332BB: connection_operation (connection.c:1175) ==24838== by 0x133D52: connection_read_thread (connection.c:1311) ==24838== by 0x1F8238: ldap_int_thread_pool_wrapper.part.0 (tpool.c:696) ==24838== by 0x486BFA2: start_thread (pthread_create.c:486) ==24838== Address 0x4ecec10 is 0 bytes inside a block of size 16 free'd ==24838== at 0x48369AB: free (vg_replace_malloc.c:530) ==24838== by 0x13FD34: backend_stopdown_one (backend.c:434) ==24838== by 0x1DF97A: pcache_db_destroy (pcache.c:4899) ==24838== by 0x19AD46: overlay_destroy_one (backover.c:1150) ==24838== by 0x124A10: config_add_internal.isra.16 (bconfig.c:5318) ==24838== by 0x125323: config_back_add (bconfig.c:5457) ==24838== by 0x13968C: fe_op_add (add.c:334) ==24838== by 0x13A49D: do_add (add.c:194) ==24838== by 0x1332BB: connection_operation (connection.c:1175) ==24838== by 0x133D52: connection_read_thread (connection.c:1311) ==24838== by 0x1F8238: ldap_int_thread_pool_wrapper.part.0 (tpool.c:696) ==24838== by 0x486BFA2: start_thread (pthread_create.c:486) ==24838== Block was alloc'd at ==24838== at 0x4837B65: calloc (vg_replace_malloc.c:752) ==24838== by 0x21FE44: ber_memcalloc_x (memory.c:283) ==24838== by 0x14DB62: ch_calloc (ch_malloc.c:104) ==24838== by 0x13F661: backend_startup_one (backend.c:200) ==24838== by 0x13F98A: backend_startup (backend.c:325) ==24838== by 0x15F920: slap_startup (init.c:219) ==24838== by 0x119D22: main (main.c:1005) ==24838==

1 0

(ITS#9182) slapd crash with invalid pcache config
by ryan＠openldap.org 11 Mar '20

11 Mar '20

Full_Name: Ryan Tandy Version: RE24 OS: Debian URL: Submission from: (NULL) (70.66.128.207) Submitted by: ryan Reported in IRC #openldap by user Dragnell, reproduced by me on current RE24. Configure slapd like so: -- include servers/slapd/schema/core.schema include servers/slapd/schema/cosine.schema include servers/slapd/schema/inetorgperson.schema database config rootpw secret database ldap -- Now try to add the following LDIF: ./clients/tools/ldapmodify -H ldap://:9000 -x -D cn=config -w secret dn: olcOverlay=pcache,olcDatabase={1}ldap,cn=config changetype: add objectClass: olcPcacheConfig olcPcache: mdb 100000 1 1000 100 olcPcacheAttrset: 0 mail olcPcacheTemplate: "(&(objectClass=inetOrgPerson)(mail=))" 0 3600 On the first attempt, the config is rejected: adding new entry "olcOverlay=pcache,olcDatabase={1}ldap,cn=config" ldap_add: Other (e.g., implementation specific) error (80) additional info: unable to parse template: AttributeDescription contains inappropriate characters If you try a second time to add the same LDIF, slapd crashes: adding new entry "olcOverlay=pcache,olcDatabase={1}ldap,cn=config" ldap_result: Can't contact LDAP server (-1) Thread 4 "slapd" received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7ffff6cf2700 (LWP 21122)] 0x000055555559cc78 in backend_stopdown_one (bd=0x7fffec102d10) at backend.c:429 429 LDAP_TAILQ_REMOVE( bd->be_pending_csn_list, csne, ce_csn_link ); (gdb) bt #0 0x000055555559cc78 in backend_stopdown_one (bd=0x7fffec102d10) at backend.c:429 #1 0x000055555568ea00 in pcache_db_destroy (be=0x5555558484f0, cr=0x0) at pcache.c:4899 #2 0x000055555561ddad in overlay_destroy_one (be=0x5555558484f0, on=0x7fffec102b30) at backover.c:1150 #3 0x0000555555574b48 in config_add_internal (cfb=0x555555765060 <cfBackInfo>, e=0x555555873598, ca=0x7ffff6cf04f0, rs=0x7ffff6cf1a80, renum=0x7ffff6cf16c0, op=0x7fffec000bb0) at bconfig.c:5318 #4 0x0000555555575131 in config_back_add (op=0x7fffec000bb0, rs=0x7ffff6cf1a80) at bconfig.c:5457 #5 0x00005555555951c7 in fe_op_add (op=0x7fffec000bb0, rs=0x7ffff6cf1a80) at add.c:334 #6 0x0000555555594ac6 in do_add (op=0x7fffec000bb0, rs=0x7ffff6cf1a80) at add.c:194 #7 0x000055555558b879 in connection_operation (ctx=0x7ffff6cf1bb0, arg_v=0x7fffec000bb0) at connection.c:1175 #8 0x000055555558bdf1 in connection_read_thread (ctx=0x7ffff6cf1bb0, argv=0x9) at connection.c:1311 #9 0x00005555556a569d in ldap_int_thread_pool_wrapper (xpool=0x5555557fbec0) at tpool.c:696 #10 0x00007ffff7f86fa3 in start_thread (arg=<optimized out>) at pthread_create.c:486 #11 0x00007ffff7eb74cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 The config in the example is invalid (due to containing a value for objectClass) and it's correct to reject it. However, slapd should not crash.

1 0

(ITS#9181) Non-initialised global options mutex causes problems on Windows
by edwin.mons＠isode.com 10 Mar '20

10 Mar '20

Full_Name: Edwin Mons Version: 2.4 OS: Windows 10 URL: http://edwinm.ik.nu/0001-Initialise-global-options-mutex.patch Submission from: (NULL) (2001:984:e0bf:1:d9ae:17ab:b829:de4f) The global options have a mutex, ldo_mutex, that is left NUL-initialised. This is no problem on must platforms where a mutex is a structure, and all NUL values is a valid mutex, but on Windows, the mutex is a handle. This handle is invalid if it's 0, which causes WaitForSingleObject to return an error. ldap_set_option tries to obtain a lock on the global options. On anything but Windows, this protects data corruption in multi-threaded use, but on Windows, it didn't: there wasn't a mutex to lock, and the result of LDAP_MUTEX_LOCK is never checked. I fixed my local build of OpenLDAP using the attached patch, which satisfied both Application Verifier, and stopped our product from crashing in certain tests that call ldap_set_options from multiple worker threads (in our case, the OpenSSL context was sometimes corrupted.)

1 0

Re: (ITS#9178) Re-connection on lost connection is not propagating LDAP_OPT_REFERRALS option set to off
by laurent.sabourin.74＠gmail.com 10 Mar '20

10 Mar '20

--000000000000f3da4d05a080be37 Content-Type: text/plain; charset="UTF-8" Hello, Please disregard, the issue was in our implementation. You can close this issue. Sorry about that! Laurent On Thu, 5 Mar 2020 at 11:50, <openldap-its(a)openldap.org> wrote: > > *** THIS IS AN AUTOMATICALLY GENERATED REPLY *** > > Thanks for your report to the OpenLDAP Issue Tracking System. Your > report has been assigned the tracking number ITS#9178. > > One of our support engineers will look at your report in due course. > Note that this may take some time because our support engineers > are volunteers. They only work on OpenLDAP when they have spare > time. > > If you need to provide additional information in regards to your > issue report, you may do so by replying to this message. Note that > any mail sent to openldap-its(a)openldap.org with (ITS#9178) > in the subject will automatically be attached to the issue report. > > mailto:openldap-its@openldap.org?subject=(ITS#9178) > > You may follow the progress of this report by loading the following > URL in a web browser: > http://www.OpenLDAP.org/its/index.cgi?findid=9178 > > Please remember to retain your issue tracking number (ITS#9178) > on any further messages you send to us regarding this report. If > you don't then you'll just waste our time and yours because we > won't be able to properly track the report. > > Please note that the Issue Tracking System is not intended to > be used to seek help in the proper use of OpenLDAP Software. > Such requests will be closed. > > OpenLDAP Software is user supported. > http://www.OpenLDAP.org/support/ > > -------------- > Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved. > > --000000000000f3da4d05a080be37 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div>Hello,</div><div><br></div>Please disregard, the issu= e was in our implementation. You can close this issue. Sorry about that!<br= ><div><br></div><div>Laurent</div></div><br><div class=3D"gmail_quote"><div= dir=3D"ltr" class=3D"gmail_attr">On Thu, 5 Mar 2020 at 11:50, <<a href= =3D"mailto:openldap-its@openldap.org">openldap-its(a)openldap.org</a>> wro= te:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px = 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br> *** THIS IS AN AUTOMATICALLY GENERATED REPLY ***<br> <br> Thanks for your report to the OpenLDAP Issue Tracking System.=C2=A0 Your<br= > report has been assigned the tracking number ITS#9178.<br> <br> One of our support engineers will look at your report in due course.<br> Note that this may take some time because our support engineers<br> are volunteers.=C2=A0 They only work on OpenLDAP when they have spare<br> time.<br> <br> If you need to provide additional information in regards to your<br> issue report, you may do so by replying to this message.=C2=A0 Note that<br= > any mail sent to <a href=3D"mailto:openldap-its@openldap.org" target=3D"_bl= ank">openldap-its(a)openldap.org</a> with (ITS#9178)<br> in the subject will automatically be attached to the issue report.<br> <br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 mailto:<a href=3D"mailto:openldap-its@openldap.= org" target=3D"_blank">openldap-its(a)openldap.org</a>?subject=3D(ITS#9178)<b= r> <br> You may follow the progress of this report by loading the following<br> URL in a web browser:<br> =C2=A0 =C2=A0 <a href=3D"http://www.OpenLDAP.org/its/index.cgi?findid=3D917= 8" rel=3D"noreferrer" target=3D"_blank">http://www.OpenLDAP.org/its/index.c= gi?findid=3D9178</a><br> <br> Please remember to retain your issue tracking number (ITS#9178)<br> on any further messages you send to us regarding this report.=C2=A0 If<br> you don't then you'll just waste our time and yours because we<br> won't be able to properly track the report.<br> <br> Please note that the Issue Tracking System is not intended to<br> be used to seek help in the proper use of OpenLDAP Software.<br> Such requests will be closed.<br> <br> OpenLDAP Software is user supported.<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 <a href=3D"http://www.OpenLDAP.org/support/" re= l=3D"noreferrer" target=3D"_blank">http://www.OpenLDAP.org/support/</a><br> <br> --------------<br> Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved.<br> <br> </blockquote></div> --000000000000f3da4d05a080be37--

1 0

(ITS#9180) Update slapo-memberOf man page about replication
by quanah＠openldap.org 09 Mar '20

09 Mar '20

Full_Name: Quanah Gibson-Mount Version: 2.4.49 OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.128.236) After discussion with Howard, slapo-memberOf should be replication compatible on REFRESH as long as the dangling option is set to ignore. The man page should be updated to reflect this, although I want to do some testing to confirm with how it behaves when refint is set to TRUE as well.

1 0

Re: (ITS#9179) back-ldap SASL proxy authorization
by ondra＠mistotebe.net 09 Mar '20

09 Mar '20

On Mon, Mar 09, 2020 at 07:47:17AM +0000, dieterbocklandt(a)gmail.com wrote: > When using SASL proxy authorization in conjunction with the identity assertion > feature of back-ldap, the authentication ID is asserted instead of the expected > authorization ID. A small concrete example (only referencing the relevant > attributes): Hi Dieter, can you post actual configuration, or even better, a script that could be used in ./tests/data/regressions? Just before you do that, I've recently set up the same and if you have your back-ldap to use SASL binds, the code seems to be checking for simple identity is there before it decides to use proxyauthz. Adding a stanza like 'binddn=cn=unused' to the idassert-bind option has worked as a workaround for now. Let me know if that helps in your case. Haven't had a chance to figure out what needs changing, so the regression script would be useful. Regards, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

(ITS#9179) back-ldap SASL proxy authorization
by dieterbocklandt＠gmail.com 09 Mar '20

09 Mar '20

Full_Name: Dieter Bocklandt Version: 2.4.49 OS: CentOS 7 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.85.78.248) When using SASL proxy authorization in conjunction with the identity assertion feature of back-ldap, the authentication ID is asserted instead of the expected authorization ID. A small concrete example (only referencing the relevant attributes): dn: cn=proxy,ou=System,dc=example,dc=net authzTo: dn:* dn: cn=service,ou=System,dc=example,dc=net authzTo: dn:uid=user,ou=People,dc=example,dc=net dn: uid=dieter,ou=People,dc=example,dc=net and the following idassert config: olcDbIDAssertBind: mode=self flags=override,prescriptive bindmethod=sasl saslmech=plain authcID=proxy credentials=XXXXX When I perform an operation like this: ldapmodify -H ldaps://ldapserver -Y PLAIN -U service -X dn:uid=dieter,ou=People,dc=example,dc=net -w servicepassword -f modifications.ldif I would assume the following takes place: - The service user binds to the consumer and assumes dieter's identity, which should be the same net effect as binding with dieter's user in the first place. - The proxy user binds to the provider and assumes dieter's identity - The provider tries to perform the write, using dieter's identity for ACL evaluation What actually happens: - The service user binds to the consumer and assumes dieter's identity - The proxy user binds to the provider and assumes the service user's identity - The provider tries to perform the write, using the service user's identity for ACL evaluation Looking a bit deeper into this, I believe the following piece of code causes this behavior: (from servers/slapd/back-ldap/bind.c in master): line 2222 - 2227: if ( !BER_BVISNULL( &op->o_conn->c_ndn ) ) { ndn = op->o_conn->c_ndn; } else { ndn = op->o_ndn; } line 2549 - 2557: if ( op->o_tag == LDAP_REQ_BIND ) { ndn = op->o_req_ndn; } else if ( !BER_BVISNULL( &op->o_conn->c_ndn ) ) { ndn = op->o_conn->c_ndn; } else { ndn = op->o_ndn; } It seems it tries to use op->o_conn->c_ndn if it's not null, which is (correct me if I'm wrong) the original authcID. That value however doesn't change when performing a proxy authorization, while op->o_ndn does properly reflect that. Shouldn't OpenLDAP always use op->o_ndn? Regards, Dieter

1 0

Re: (ITS#9037) observing crash in mdb_cursor_put()
by hyc＠symas.com 08 Mar '20

08 Mar '20

hyc(a)symas.com wrote: > Robins George wrote: >> Hello Howard, > > Hello again. Revisiting this trace and walkthrough: > >> we are not able to reproduce the issue consistently so test code is not available at this time, and I do believe this issue will be present in the latest code as well since Myk also reported the same.. Attaching analysis from our side, hope it helps. >> >> The call stack what we have seen is, >> >> #0 0x0011b62e in mdb_cursor_put (mc=0xffe52d18, key=0xffe52e74, data=0xffe52e6c, flags=0) at mdb.c:6688 >> #1 0x0011c8ec in mdb_put (txn=0xdc13f008, dbi=2, key=0xffe52e74, data=0xffe52e6c, flags=0) at mdb.c:8771 >> #2 0x00b792b8 in LMDB::LMDBContext::createSession (this=0x80ca418, sid=0x8297be4 "sidebf3708f0fd9fcb8e062529da47adf51402dfc4600000000+") at lmdbint.cc:460 >> #3 0x08053564 in updateLMDB (request=..., forward=@0xffe5315f) at sessionserver.cc:1075 >> #4 processRequestWithoutResponse (request=..., forward=@0xffe5315f) at sessionserver.cc:1160 >> #5 0x08056a80 in processRequest (this=0x80b2ac0, fd=33) at sessionserver.cc:1189 >> #6 readFromSock (this=0x80b2ac0, fd=33) at sessionserver.cc:1342 >> #7 SockHandler::ioReady (this=0x80b2ac0, fd=33) at sessionserver.cc:1455 >> #8 0x00ba2592 in runCoreDispatcher (default_t=<value optimized out>, flags=-1) at fds.cc:889 >> #9 0x00ba2ff7 in DSEvntFds::runDispatcher () at fds.cc:945 >> #10 0x080559c6 in main () at sessionserver.cc:1739 >> >> Here it is helpful to examine frames #0 and #1 in detail in relation to the relevant source code /libraries/liblmdb/mdb.c. >> >> Frame #1 >> >> #1 0x0011c8ec in mdb_put (txn=0xdc13f008, dbi=2, key=0xffe52e74, data=0xffe52e6c, flags=0) at mdb.c:8771 >> mc = {mc_next = 0x0, mc_backup = 0x0, mc_xcursor = 0x0, mc_txn = 0xdc13f008, mc_dbi = 2, mc_db = 0xdc13f088, mc_dbx = 0xe1215038, mc_dbflag = 0xdc1cf09a "\033", '\032' <repeats 51 times>, mc_snum = 0, mc_top = 0, mc_flags = 0, mc_pg = {0x0, 0x80b2ac0, 0xffe52d68, 0x28afce, 0xdc13f008, 0x80ce9b0, 0xffe52dc8, 0x4c5ff4, 0x2b, 0x80b2ac0, 0xffe52d98, 0x49209a, 0x2b, 0x4c5ff4, 0x2121cb, 0x21576c, 0x8297d34, 0x3497af, 0x21576c, 0x21316a, 0x8297d34, 0x80ac7b0, 0x1e, 0x46eed6, 0x2b, 0x0, 0x80ce9b0, 0x4c5ff4, 0x80ac7b0, 0x8297d34, 0xffe52df8, 0x46fb96}, mc_ki = {0, 2089, 51120, 2058, 30, 0, 16796, 17, 11760, 65509, 3, 0, 32040, 2089, 30, 0, 0, 0, 0, 0, 3, 0, 24564, 76, 51120, 2058, 10944, 2059, 11800, 65509, 64758, 70}} <-------- >> >> mx = {mx_cursor = {mc_next = 0x38, mc_backup = 0x3, mc_xcursor = 0x0, mc_txn = 0x0, mc_dbi = 0, mc_db = 0x28, mc_dbx = 0x0, mc_dbflag = 0x0, mc_snum = 3, mc_top = 0, mc_flags = 17, mc_pg = {0x3a93d8, 0x10, 0x0, 0x18, 0x3a93a0, 0x0, 0x3a93d0, 0x289abe, 0x3a93a0, 0xffe52d3f, 0xffe52c68, 0x28afce, 0xffe52dbc, 0xffe52db4, 0x3, 0x4c5ff4, 0x11, 0x36c99b, 0x6e, 0x77, 0x7c, 0x5b, 0x38, 0x289abe, 0x0, 0x0, 0x0, 0x28, 0x0, 0x0, 0x3, 0x10}, mc_ki = {37848, 58, 51611, 54, 110, 0, 119, 0, 124, 0, 91, 0, 58, 0, 39614, 40, 0, 0, 0, 0, 0, 0, 160, 0, 0, 0, 2, 0, 18, 0, 136, 0}}, mx_db = {md_pad = 3838936, md_flags = 51611, md_depth = 54, md_branch_pages = 110, md_leaf_pages = 119, md_overflow_pages = 124, md_entries = 91, md_root = 56}, mx_dbx = {md_name = {mv_size = 6, mv_data = 0x0}, md_cmp = 0, md_dcmp = 0, md_rel = 0x40, md_relctx = 0x0}, mx_dbflag = 0 '\000'} >> rc = 0 >> >> And source code for mdb_put() is from mdb.c >> >> int >> mdb_put(MDB_txn *txn, MDB_dbi dbi, >> MDB_val *key, MDB_val *data, unsigned int flags) >> { >> MDB_cursor mc; >> MDB_xcursor mx; >> int rc; >> >> if (!key || !data || !TXN_DBI_EXIST(txn, dbi, DB_USRVALID)) >> return EINVAL; >> >> if (flags & ~(MDB_NOOVERWRITE|MDB_NODUPDATA|MDB_RESERVE|MDB_APPEND|MDB_APPENDDUP)) >> return EINVAL; >> >> if (txn->mt_flags & (MDB_TXN_RDONLY|MDB_TXN_BLOCKED)) >> return (txn->mt_flags & MDB_TXN_RDONLY) ? EACCES : MDB_BAD_TXN; >> >> mdb_cursor_init(&mc, txn, dbi, &mx); <-------- see source code below >> mc.mc_next = txn->mt_cursors[dbi]; >> txn->mt_cursors[dbi] = &mc; >> rc = mdb_cursor_put(&mc, key, data, flags); <-------- see Frame #0 >> txn->mt_cursors[dbi] = mc.mc_next; >> return rc; >> } >> >> >> Source Code For mdb_cursor_init() From mdb.c >> /** Initialize a cursor for a given transaction and database. */ >> static void >> mdb_cursor_init(MDB_cursor *mc, MDB_txn *txn, MDB_dbi dbi, MDB_xcursor *mx) >> { >> mc->mc_next = NULL; >> mc->mc_backup = NULL; >> mc->mc_dbi = dbi; >> mc->mc_txn = txn; >> mc->mc_db = &txn->mt_dbs[dbi]; >> mc->mc_dbx = &txn->mt_dbxs[dbi]; >> mc->mc_dbflag = &txn->mt_dbflags[dbi]; >> mc->mc_snum = 0; <-------- >> mc->mc_top = 0; <-------- >> mc->mc_pg[0] = 0; <-------- >> mc->mc_ki[0] = 0; >> mc->mc_flags = 0; >> if (txn->mt_dbs[dbi].md_flags & MDB_DUPSORT) { >> mdb_tassert(txn, mx != NULL); >> mc->mc_xcursor = mx; >> mdb_xcursor_init0(mc); >> } else { >> mc->mc_xcursor = NULL; >> } >> if (*mc->mc_dbflag & DB_STALE) { <-------- false *mc->mc_dbflag = 27, DB_STALE = 0x02 /**< Named-DB record is older than txnID */ > > 27 = 0x1B, this DB is stale and this test is true, not false. > >> mdb_page_search(mc, NULL, MDB_PS_ROOTONLY); >> } >> } >> >> From this we know that when mdb_cursor_put() is called, the following values remain assigned: >> >> mc->mc_snum = 0; <-------- >> mc->mc_top = 0; <-------- >> mc->mc_pg[0] = 0; <-------- >> >> and its noted these two values still have their initial values at the time of the segmentation fault. >> >> (gdb) fr 0 >> #0 0x0011b62e in mdb_cursor_put (mc=0xffe52d18, key=0xffe52e74, data=0xffe52e6c, flags=0) at mdb.c:6688 >> 6688 in mdb.c >> (gdb) p mc->mc_top >> $1 = 0 >> (gdb) p mc->mc_pg[mc->mc_top] >> $19 = (MDB_page *) 0x0 >> >> Let us consider how the path taken through mdb_cursor_put() could account for these null variable values which result in a segmentation fault. >> >> Frame #0 >> >> #0 0x0011b62e in mdb_cursor_put (mc=0xffe52d18, key=0xffe52e74, data=0xffe52e6c, flags=0) at mdb.c:6688 <-------- flags = 0 >> env = 0x80ce9b0 >> leaf = <value optimized out> >> fp = <value optimized out> >> mp = 0x38 >> sub_root = 0x0 >> fp_flags = <value optimized out> >> xdata = {mv_size = 3838880, mv_data = 0xdc1cf09a} >> rdata = 0xffe52e6c >> dkey = {mv_size = 0, mv_data = 0x3a93cc} >> olddata = {mv_size = 22, mv_data = 0x36c820} >> dummy = {md_pad = 22, md_flags = 11128, md_depth = 65509, md_branch_pages = 16, md_leaf_pages = 1507329, md_overflow_pages = 0, md_entries = 3838928, md_root = 3833844} >> do_sub = 0 >> insert_key = -30798 <-------- #define MDB_NOTFOUND (-30798) >> insert_data = -30798 <-------- #define MDB_NOTFOUND (-30798) >> mcount = 0 >> dcount = 0 >> nospill = 0 <-------- >> nsize = <value optimized out> >> rc = 0 >> rc2 = <value optimized out> >> nflags = 0 <-------- >> __func__ = "mdb_cursor_put" >> >> We know that mc->mc_top and mc->mc_pg[0] were initialized to 0 in mdb_cursor_init(). As my annotations of the source code below suggest, careful analysis reveals that the paths actually taken through mdb_cursor_put() do not modify these assignments. >> >> Excerpted Source Code For mdb_cursor_put() From mdb.c >> >> int >> mdb_cursor_put(MDB_cursor *mc, MDB_val *key, MDB_val *data, >> unsigned int flags) >> { >> MDB_env *env; >> MDB_node *leaf = NULL; >> MDB_page *fp, *mp, *sub_root = NULL; >> uint16_t fp_flags; >> MDB_val xdata, *rdata, dkey, olddata; >> MDB_db dummy; >> int do_sub = 0, insert_key, insert_data; >> unsigned int mcount = 0, dcount = 0, nospill; >> size_t nsize; >> int rc, rc2; >> unsigned int nflags; >> DKBUF; >> >> if (mc == NULL || key == NULL) >> return EINVAL; >> >> env = mc->mc_txn->mt_env; >> >> /* Check this first so counter will always be zero on any >> * early failures. >> */ >> if (flags & MDB_MULTIPLE) { >> dcount = data[1].mv_size; >> data[1].mv_size = 0; >> if (!F_ISSET(mc->mc_db->md_flags, MDB_DUPFIXED)) >> return MDB_INCOMPATIBLE; >> } >> >> nospill = flags & MDB_NOSPILL; >> flags &= ~MDB_NOSPILL; >> >> if (mc->mc_txn->mt_flags & (MDB_TXN_RDONLY|MDB_TXN_BLOCKED)) >> return (mc->mc_txn->mt_flags & MDB_TXN_RDONLY) ? EACCES : MDB_BAD_TXN; >> >> if (key->mv_size-1 >= ENV_MAXKEY(env)) >> return MDB_BAD_VALSIZE; >> >> #if SIZE_MAX > MAXDATASIZE >> if (data->mv_size > ((mc->mc_db->md_flags & MDB_DUPSORT) ? ENV_MAXKEY(env) : MAXDATASIZE)) >> return MDB_BAD_VALSIZE; >> #else >> if ((mc->mc_db->md_flags & MDB_DUPSORT) && data->mv_size > ENV_MAXKEY(env)) >> return MDB_BAD_VALSIZE; >> #endif >> >> DPRINTF(("==> put db %d key [%s], size %"Z"u, data size %"Z"u", >> DDBI(mc), DKEY(key), key ? key->mv_size : 0, data->mv_size)); >> >> dkey.mv_size = 0; >> >> if (flags == MDB_CURRENT) { <-------- false flags = 0 >> if (!(mc->mc_flags & C_INITIALIZED)) >> return EINVAL; >> rc = MDB_SUCCESS; >> } else if (mc->mc_db->md_root == P_INVALID) { <-------- false, mc->mc_db->md_root = 68 > > I might have missed it, did you show the entire contents of *mc->mc_db somewhere? > >> /* new database, cursor has nothing to point to */ >> mc->mc_snum = 0; >> mc->mc_top = 0; >> mc->mc_flags &= ~C_INITIALIZED; >> rc = MDB_NO_ROOT; >> } else { <-------- executed >> int exact = 0; >> MDB_val d2; >> if (flags & MDB_APPEND) { <-------- false flags = 0 >> MDB_val k2; >> rc = mdb_cursor_last(mc, &k2, &d2); >> if (rc == 0) { >> rc = mc->mc_dbx->md_cmp(key, &k2); >> if (rc > 0) { >> rc = MDB_NOTFOUND; >> mc->mc_ki[mc->mc_top]++; >> } else { >> /* new key is <= last key */ >> rc = MDB_KEYEXIST; >> } >> } >> } else {<-------- executed >> rc = mdb_cursor_set(mc, key, &d2, MDB_SET, &exact); <-------- returns -30798 which is MDB_NOTFOUND > > This is an important step. mdb_cursor_set only returns MDB_NOTFOUND when mc->mc_pg[mc->mc_top] != NULL. > There are no code paths that can return this error code without setting the rootpage pointer mc->mc_pg[0] non-NULL. > The only path that can allow this is if mc->mc_db->md_root == P_INVALID (the tree is empty) and we already know > that's not true in this case. Nothing in LMDB will change these values between the time mdb_cursor_set > returned and the time that mdb_cursor_put tries to reference mc->mc_pg[]. As such this sounds like a > memory overwrite corruption from some other thread, unrelated to LMDB. > You can verify this by adding an assert after the mdb_cursor_set() call: mdb_cassert(mc, rc != MDB_NOTFOUND || mc->mc_pg != NULL); At this point I would check to see if your threads' stack sizes are large enough. Since this cursor came from mdb_put, it lives on the stack, and a stack overrun is the most likely culprit. -- -- 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#9037) observing crash in mdb_cursor_put()
by hyc＠symas.com 08 Mar '20

08 Mar '20

Robins George wrote: > Hello Howard, Hello again. Revisiting this trace and walkthrough: > we are not able to reproduce the issue consistently so test code is not available at this time, and I do believe this issue will be present in the latest code as well since Myk also reported the same.. Attaching analysis from our side, hope it helps. > > The call stack what we have seen is, > > #0 0x0011b62e in mdb_cursor_put (mc=0xffe52d18, key=0xffe52e74, data=0xffe52e6c, flags=0) at mdb.c:6688 > #1 0x0011c8ec in mdb_put (txn=0xdc13f008, dbi=2, key=0xffe52e74, data=0xffe52e6c, flags=0) at mdb.c:8771 > #2 0x00b792b8 in LMDB::LMDBContext::createSession (this=0x80ca418, sid=0x8297be4 "sidebf3708f0fd9fcb8e062529da47adf51402dfc4600000000+") at lmdbint.cc:460 > #3 0x08053564 in updateLMDB (request=..., forward=@0xffe5315f) at sessionserver.cc:1075 > #4 processRequestWithoutResponse (request=..., forward=@0xffe5315f) at sessionserver.cc:1160 > #5 0x08056a80 in processRequest (this=0x80b2ac0, fd=33) at sessionserver.cc:1189 > #6 readFromSock (this=0x80b2ac0, fd=33) at sessionserver.cc:1342 > #7 SockHandler::ioReady (this=0x80b2ac0, fd=33) at sessionserver.cc:1455 > #8 0x00ba2592 in runCoreDispatcher (default_t=<value optimized out>, flags=-1) at fds.cc:889 > #9 0x00ba2ff7 in DSEvntFds::runDispatcher () at fds.cc:945 > #10 0x080559c6 in main () at sessionserver.cc:1739 > > Here it is helpful to examine frames #0 and #1 in detail in relation to the relevant source code /libraries/liblmdb/mdb.c. > > Frame #1 > > #1 0x0011c8ec in mdb_put (txn=0xdc13f008, dbi=2, key=0xffe52e74, data=0xffe52e6c, flags=0) at mdb.c:8771 > mc = {mc_next = 0x0, mc_backup = 0x0, mc_xcursor = 0x0, mc_txn = 0xdc13f008, mc_dbi = 2, mc_db = 0xdc13f088, mc_dbx = 0xe1215038, mc_dbflag = 0xdc1cf09a "\033", '\032' <repeats 51 times>, mc_snum = 0, mc_top = 0, mc_flags = 0, mc_pg = {0x0, 0x80b2ac0, 0xffe52d68, 0x28afce, 0xdc13f008, 0x80ce9b0, 0xffe52dc8, 0x4c5ff4, 0x2b, 0x80b2ac0, 0xffe52d98, 0x49209a, 0x2b, 0x4c5ff4, 0x2121cb, 0x21576c, 0x8297d34, 0x3497af, 0x21576c, 0x21316a, 0x8297d34, 0x80ac7b0, 0x1e, 0x46eed6, 0x2b, 0x0, 0x80ce9b0, 0x4c5ff4, 0x80ac7b0, 0x8297d34, 0xffe52df8, 0x46fb96}, mc_ki = {0, 2089, 51120, 2058, 30, 0, 16796, 17, 11760, 65509, 3, 0, 32040, 2089, 30, 0, 0, 0, 0, 0, 3, 0, 24564, 76, 51120, 2058, 10944, 2059, 11800, 65509, 64758, 70}} <-------- > > mx = {mx_cursor = {mc_next = 0x38, mc_backup = 0x3, mc_xcursor = 0x0, mc_txn = 0x0, mc_dbi = 0, mc_db = 0x28, mc_dbx = 0x0, mc_dbflag = 0x0, mc_snum = 3, mc_top = 0, mc_flags = 17, mc_pg = {0x3a93d8, 0x10, 0x0, 0x18, 0x3a93a0, 0x0, 0x3a93d0, 0x289abe, 0x3a93a0, 0xffe52d3f, 0xffe52c68, 0x28afce, 0xffe52dbc, 0xffe52db4, 0x3, 0x4c5ff4, 0x11, 0x36c99b, 0x6e, 0x77, 0x7c, 0x5b, 0x38, 0x289abe, 0x0, 0x0, 0x0, 0x28, 0x0, 0x0, 0x3, 0x10}, mc_ki = {37848, 58, 51611, 54, 110, 0, 119, 0, 124, 0, 91, 0, 58, 0, 39614, 40, 0, 0, 0, 0, 0, 0, 160, 0, 0, 0, 2, 0, 18, 0, 136, 0}}, mx_db = {md_pad = 3838936, md_flags = 51611, md_depth = 54, md_branch_pages = 110, md_leaf_pages = 119, md_overflow_pages = 124, md_entries = 91, md_root = 56}, mx_dbx = {md_name = {mv_size = 6, mv_data = 0x0}, md_cmp = 0, md_dcmp = 0, md_rel = 0x40, md_relctx = 0x0}, mx_dbflag = 0 '\000'} > rc = 0 > > And source code for mdb_put() is from mdb.c > > int > mdb_put(MDB_txn *txn, MDB_dbi dbi, > MDB_val *key, MDB_val *data, unsigned int flags) > { > MDB_cursor mc; > MDB_xcursor mx; > int rc; > > if (!key || !data || !TXN_DBI_EXIST(txn, dbi, DB_USRVALID)) > return EINVAL; > > if (flags & ~(MDB_NOOVERWRITE|MDB_NODUPDATA|MDB_RESERVE|MDB_APPEND|MDB_APPENDDUP)) > return EINVAL; > > if (txn->mt_flags & (MDB_TXN_RDONLY|MDB_TXN_BLOCKED)) > return (txn->mt_flags & MDB_TXN_RDONLY) ? EACCES : MDB_BAD_TXN; > > mdb_cursor_init(&mc, txn, dbi, &mx); <-------- see source code below > mc.mc_next = txn->mt_cursors[dbi]; > txn->mt_cursors[dbi] = &mc; > rc = mdb_cursor_put(&mc, key, data, flags); <-------- see Frame #0 > txn->mt_cursors[dbi] = mc.mc_next; > return rc; > } > > > Source Code For mdb_cursor_init() From mdb.c > /** Initialize a cursor for a given transaction and database. */ > static void > mdb_cursor_init(MDB_cursor *mc, MDB_txn *txn, MDB_dbi dbi, MDB_xcursor *mx) > { > mc->mc_next = NULL; > mc->mc_backup = NULL; > mc->mc_dbi = dbi; > mc->mc_txn = txn; > mc->mc_db = &txn->mt_dbs[dbi]; > mc->mc_dbx = &txn->mt_dbxs[dbi]; > mc->mc_dbflag = &txn->mt_dbflags[dbi]; > mc->mc_snum = 0; <-------- > mc->mc_top = 0; <-------- > mc->mc_pg[0] = 0; <-------- > mc->mc_ki[0] = 0; > mc->mc_flags = 0; > if (txn->mt_dbs[dbi].md_flags & MDB_DUPSORT) { > mdb_tassert(txn, mx != NULL); > mc->mc_xcursor = mx; > mdb_xcursor_init0(mc); > } else { > mc->mc_xcursor = NULL; > } > if (*mc->mc_dbflag & DB_STALE) { <-------- false *mc->mc_dbflag = 27, DB_STALE = 0x02 /**< Named-DB record is older than txnID */ 27 = 0x1B, this DB is stale and this test is true, not false. > mdb_page_search(mc, NULL, MDB_PS_ROOTONLY); > } > } > > From this we know that when mdb_cursor_put() is called, the following values remain assigned: > > mc->mc_snum = 0; <-------- > mc->mc_top = 0; <-------- > mc->mc_pg[0] = 0; <-------- > > and its noted these two values still have their initial values at the time of the segmentation fault. > > (gdb) fr 0 > #0 0x0011b62e in mdb_cursor_put (mc=0xffe52d18, key=0xffe52e74, data=0xffe52e6c, flags=0) at mdb.c:6688 > 6688 in mdb.c > (gdb) p mc->mc_top > $1 = 0 > (gdb) p mc->mc_pg[mc->mc_top] > $19 = (MDB_page *) 0x0 > > Let us consider how the path taken through mdb_cursor_put() could account for these null variable values which result in a segmentation fault. > > Frame #0 > > #0 0x0011b62e in mdb_cursor_put (mc=0xffe52d18, key=0xffe52e74, data=0xffe52e6c, flags=0) at mdb.c:6688 <-------- flags = 0 > env = 0x80ce9b0 > leaf = <value optimized out> > fp = <value optimized out> > mp = 0x38 > sub_root = 0x0 > fp_flags = <value optimized out> > xdata = {mv_size = 3838880, mv_data = 0xdc1cf09a} > rdata = 0xffe52e6c > dkey = {mv_size = 0, mv_data = 0x3a93cc} > olddata = {mv_size = 22, mv_data = 0x36c820} > dummy = {md_pad = 22, md_flags = 11128, md_depth = 65509, md_branch_pages = 16, md_leaf_pages = 1507329, md_overflow_pages = 0, md_entries = 3838928, md_root = 3833844} > do_sub = 0 > insert_key = -30798 <-------- #define MDB_NOTFOUND (-30798) > insert_data = -30798 <-------- #define MDB_NOTFOUND (-30798) > mcount = 0 > dcount = 0 > nospill = 0 <-------- > nsize = <value optimized out> > rc = 0 > rc2 = <value optimized out> > nflags = 0 <-------- > __func__ = "mdb_cursor_put" > > We know that mc->mc_top and mc->mc_pg[0] were initialized to 0 in mdb_cursor_init(). As my annotations of the source code below suggest, careful analysis reveals that the paths actually taken through mdb_cursor_put() do not modify these assignments. > > Excerpted Source Code For mdb_cursor_put() From mdb.c > > int > mdb_cursor_put(MDB_cursor *mc, MDB_val *key, MDB_val *data, > unsigned int flags) > { > MDB_env *env; > MDB_node *leaf = NULL; > MDB_page *fp, *mp, *sub_root = NULL; > uint16_t fp_flags; > MDB_val xdata, *rdata, dkey, olddata; > MDB_db dummy; > int do_sub = 0, insert_key, insert_data; > unsigned int mcount = 0, dcount = 0, nospill; > size_t nsize; > int rc, rc2; > unsigned int nflags; > DKBUF; > > if (mc == NULL || key == NULL) > return EINVAL; > > env = mc->mc_txn->mt_env; > > /* Check this first so counter will always be zero on any > * early failures. > */ > if (flags & MDB_MULTIPLE) { > dcount = data[1].mv_size; > data[1].mv_size = 0; > if (!F_ISSET(mc->mc_db->md_flags, MDB_DUPFIXED)) > return MDB_INCOMPATIBLE; > } > > nospill = flags & MDB_NOSPILL; > flags &= ~MDB_NOSPILL; > > if (mc->mc_txn->mt_flags & (MDB_TXN_RDONLY|MDB_TXN_BLOCKED)) > return (mc->mc_txn->mt_flags & MDB_TXN_RDONLY) ? EACCES : MDB_BAD_TXN; > > if (key->mv_size-1 >= ENV_MAXKEY(env)) > return MDB_BAD_VALSIZE; > > #if SIZE_MAX > MAXDATASIZE > if (data->mv_size > ((mc->mc_db->md_flags & MDB_DUPSORT) ? ENV_MAXKEY(env) : MAXDATASIZE)) > return MDB_BAD_VALSIZE; > #else > if ((mc->mc_db->md_flags & MDB_DUPSORT) && data->mv_size > ENV_MAXKEY(env)) > return MDB_BAD_VALSIZE; > #endif > > DPRINTF(("==> put db %d key [%s], size %"Z"u, data size %"Z"u", > DDBI(mc), DKEY(key), key ? key->mv_size : 0, data->mv_size)); > > dkey.mv_size = 0; > > if (flags == MDB_CURRENT) { <-------- false flags = 0 > if (!(mc->mc_flags & C_INITIALIZED)) > return EINVAL; > rc = MDB_SUCCESS; > } else if (mc->mc_db->md_root == P_INVALID) { <-------- false, mc->mc_db->md_root = 68 I might have missed it, did you show the entire contents of *mc->mc_db somewhere? > /* new database, cursor has nothing to point to */ > mc->mc_snum = 0; > mc->mc_top = 0; > mc->mc_flags &= ~C_INITIALIZED; > rc = MDB_NO_ROOT; > } else { <-------- executed > int exact = 0; > MDB_val d2; > if (flags & MDB_APPEND) { <-------- false flags = 0 > MDB_val k2; > rc = mdb_cursor_last(mc, &k2, &d2); > if (rc == 0) { > rc = mc->mc_dbx->md_cmp(key, &k2); > if (rc > 0) { > rc = MDB_NOTFOUND; > mc->mc_ki[mc->mc_top]++; > } else { > /* new key is <= last key */ > rc = MDB_KEYEXIST; > } > } > } else {<-------- executed > rc = mdb_cursor_set(mc, key, &d2, MDB_SET, &exact); <-------- returns -30798 which is MDB_NOTFOUND This is an important step. mdb_cursor_set only returns MDB_NOTFOUND when mc->mc_pg[mc->mc_top] != NULL. There are no code paths that can return this error code without setting the rootpage pointer mc->mc_pg[0] non-NULL. The only path that can allow this is if mc->mc_db->md_root == P_INVALID (the tree is empty) and we already know that's not true in this case. Nothing in LMDB will change these values between the time mdb_cursor_set returned and the time that mdb_cursor_put tries to reference mc->mc_pg[]. As such this sounds like a memory overwrite corruption from some other thread, unrelated to LMDB. -- -- 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#8639) Remove support for LANMAN
by ryan＠nardis.ca 07 Mar '20

07 Mar '20

Tested smbk5pwd with Samba 4.9.5 (both openssl and gnutls). Works for me, so pushed to master now. Further testing would be appreciated.

1 0

(ITS#9178) Re-connection on lost connection is not propagating LDAP_OPT_REFERRALS option set to off
by laurent.sabourin.74＠gmail.com 05 Mar '20

05 Mar '20

Full_Name: Laurent Sabourin Version: openldap-2.4.48 OS: Windows URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (216.218.42.174) I am using OpenLDAP libraries within my software for my LDAP client implementation. For the LDAP session handles where I set the option LDAP_OPT_REFERRALS to LDAP_OPT_OFF, it seems that that option is not being propagated when OpenLDAP reconnects after the server dropped the initial connection. Because of that, all subsequent searches start following referrals even though the option was turned off initially. How to reproduce: 1- Make a LDAP search to LDAP server that returns referrals (Windows AD in my case) with referrals turned off. The search doesn't follow referrals. 2- Drop the connection with the LDAP server (I used SysInternals TCPView to force the connection to close) 3- Make the same LDAP search using the same LDAP session handle used in step 1. OpenLDAP reconnects, but the search unexpectedly follows the referrals. Expected behavior: I would expect the LDAP session handle to retain original options even when it reconnects drop connections.

1 0

Re: (ITS#8639) Remove support for LANMAN
by ryan＠nardis.ca 05 Mar '20

05 Mar '20

I put up my WIP branch on github: https://github.com/openldap/openldap/compare/master...rtandy:its8639 Still need to finish testing smbk5pwd before I can push it.

1 0

(ITS#9177) Finish the autoconf 2.69 upgrade
by ryan＠openldap.org 28 Feb '20

28 Feb '20

Full_Name: Ryan Tandy Version: master OS: URL: Submission from: (NULL) (70.66.128.207) Submitted by: ryan autoconf 2.69 upgrade was only partially completed. So far we have autoconf (6b81910fc) and autoheader (c2f75cd10). However running autoreconf 2.69 still generates more diffs. At least aclocal still needs to be run. This ITS is a reminder to check what else autoreconf does and check in the remaining changes. In future it might be good practice to get in the habit of running autoreconf instead of just autoconf. It tries and fails to run Automake, but that can probably be addressed (possibly by deleting the AM_INIT_AUTOMAKE call).

1 0

Re: (ITS#8639) Remove support for LANMAN
by michael＠stroeder.com 28 Feb '20

28 Feb '20

On 2/28/20 8:40 PM, ryan(a)nardis.ca wrote: > Are you aware of any scenarios where > sambaLMPassword is actually required today? Personally I'm more inclined > to just delete the code rather than #ifdef it; people can always grab > the older code if they really need that. +1 for hunking out LANMAN hashes completely. Ciao, Michael.

1 0

Re: (ITS#8639) Remove support for LANMAN
by ryan＠nardis.ca 28 Feb '20

28 Feb '20

Hello, On Thu, Feb 20, 2020 at 03:50:38PM +0000, fumiyas(a)osstech.co.jp wrote: >I've created a path for smbk5pwd to disable the insecure sambaLMPassword >support by default. Thanks for this patch. Are you aware of any scenarios where sambaLMPassword is actually required today? Personally I'm more inclined to just delete the code rather than #ifdef it; people can always grab the older code if they really need that.

1 0

Re: (ITS#9171) slapd with ppolicy and pwdAccountLockedTime crashes
by tokos＠ipp.cas.cz 22 Feb '20

22 Feb '20

--000000000000b0a76e059f255a73 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Ondrej, I really appreciate so quick fix. Regards Stanislav p=C3=A1 21. 2. 2020 v 11:49 odes=C3=ADlatel Ond=C5=99ej Kuzn=C3=ADk <ondra@= mistotebe.net> napsal: > On Mon, Feb 17, 2020 at 02:17:32PM +0000, tokos(a)ipp.cas.cz wrote: > > Hi Ondrej, > > > > I uploaded my configuration here(ftp.openldap.org/incoming) : > > Hi Stanislav, > thanks for the information, I have been able to reproduce the issue and > pushed a fix to master (commit 140b676bc1bd786f9fd1e7b047981e84b57cb354). > > Regards, > > -- > Ond=C5=99ej Kuzn=C3=ADk > Senior Software Engineer > Symas Corporation http://www.symas.com > Packaged, certified, and supported LDAP solutions powered by OpenLDAP > --000000000000b0a76e059f255a73 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div>Hi Ondrej,</div><div><br></div><div>=C2=A0 I really a= ppreciate so quick fix. <br></div><div><br></div><div>Regards</div><div><br= ></div><div>Stanislav<br></div></div><br><div class=3D"gmail_quote"><div di= r=3D"ltr" class=3D"gmail_attr">p=C3=A1 21. 2. 2020 v=C2=A011:49 odes=C3=ADl= atel Ond=C5=99ej Kuzn=C3=ADk <<a href=3D"mailto:ondra@mistotebe.net">ond= ra(a)mistotebe.net</a>> napsal:<br></div><blockquote class=3D"gmail_quote"= style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);p= adding-left:1ex">On Mon, Feb 17, 2020 at 02:17:32PM +0000, <a href=3D"mailt= o:tokos@ipp.cas.cz" target=3D"_blank">tokos(a)ipp.cas.cz</a> wrote:<br> > Hi Ondrej,<br> > <br> >=C2=A0 =C2=A0I uploaded my configuration here(<a href=3D"http://ftp.ope= nldap.org/incoming" rel=3D"noreferrer" target=3D"_blank">ftp.openldap.org/i= ncoming</a>) :<br> <br> Hi Stanislav,<br> thanks for the information, I have been able to reproduce the issue and<br> pushed a fix to master (commit 140b676bc1bd786f9fd1e7b047981e84b57cb354).<b= r> <br> Regards,<br> <br> -- <br> Ond=C5=99ej Kuzn=C3=ADk<br> Senior Software Engineer<br> Symas Corporation=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0<a href=3D"http://www.symas.com" rel=3D"noreferr= er" target=3D"_blank">http://www.symas.com</a><br> Packaged, certified, and supported LDAP solutions powered by OpenLDAP<br> </blockquote></div> --000000000000b0a76e059f255a73--

1 0

Re: (ITS#9175) ldapsearch segfault
by quanah＠symas.com 21 Feb '20

21 Feb '20

Thanks for the report, suggested fix has been applied. Regards, Quanah --On Friday, February 21, 2020 8:38 PM +0000 lhaley(a)meditech.com wrote: > --0000000000003b4d37059f1c0189 > Content-Type: text/plain; charset="UTF-8" > Content-Transfer-Encoding: quoted-printable > > footnote: In my first followup, I intended to write "as I am quite > UNaccustomed to working with the data" > Cheers > > On Fri, Feb 21, 2020 at 3:27 PM Lexi Haley <lhaley(a)meditech.com> wrote: > >> FOUND THE ISSUE! So - in GDB , while paused in the "{mM}" processing >> tha= > t >> ber_scanf does (called from ldap_get_attribute_ber), I kept seeing the >> variable arguments list not properly setting off --- and sure enough, >> digging in memory, on the stack was 0x100000000 ... which was the cause >> = > of >> the eventual segfault. >> >> Well, backtracking to the ber_scanf call itself, I see a zero 0 which >> isn't cast to the ber_len_t type, and as such, will only occupy 4 bytes >> a= > s >> a sizeof int - instead of (( on my system 8, for sizeof (ber_len_t). So >> = > - >> the solution was just to cast the argument. So that the cookie.off =3D >> va_arg( ap, ber_len_t ); will unpack only bytes we've intentionally sent >> = > it >> -- not garbage left over. >> >> So - the change suggested is: >> >> >> diff --git a/libraries/libldap/getattr.c b/libraries/libldap/getattr.c >> index 31784d765..0300ea574 100644 >> --- a/libraries/libldap/getattr.c >> +++ b/libraries/libldap/getattr.c >> @@ -147,7 +147,7 @@ ldap_get_attribute_ber( LDAP *ld, LDAPMessage *entry, >> BerElement *ber, >> >> /* skip sequence, snarf attribute type */ >> tag =3D ber_scanf( ber, vals ? "{mM}" : "{mx}", attr, >> val= > s, >> - &siz, 0 ); >> + &siz, (ber_len_t)0 ); >> if( tag =3D=3D LBER_ERROR ) { >> rc =3D ld->ld_errno =3D LDAP_DECODING_ERROR; >> } >> >> >> I hope you can take this haphazard issue submit, and do whatever is right >> with it - to get this patch considered. Thanks! >> >> >> >> On Fri, Feb 21, 2020 at 1:06 PM Lexi Haley <lhaley(a)meditech.com> wrote: >> >>> continuing notes - as I am quite accustomed to working with the data >>> structures and processes for LDAP - my hacky fudge was just that - and >>> a= > lso >>> useless. By bailing out at that point, ldapsearch doesn't list the >>> tag=3Dvalue results. I am continuing to dig around ... >>> >>> Lexi >>> >>> On Thu, Feb 20, 2020 at 3:09 PM <openldap-its(a)openldap.org> wrote: >>> >>>> >>>> *** THIS IS AN AUTOMATICALLY GENERATED REPLY *** >>>> >>>> Thanks for your report to the OpenLDAP Issue Tracking System. Your >>>> report has been assigned the tracking number ITS#9175. >>>> >>>> One of our support engineers will look at your report in due course. >>>> Note that this may take some time because our support engineers >>>> are volunteers. They only work on OpenLDAP when they have spare >>>> time. >>>> >>>> If you need to provide additional information in regards to your >>>> issue report, you may do so by replying to this message. Note that >>>> any mail sent to openldap-its(a)openldap.org with (ITS#9175) >>>> in the subject will automatically be attached to the issue report. >>>> >>>> mailto:openldap-its@openldap.org?subject=3D(ITS#9175) >>>> >>>> You may follow the progress of this report by loading the following >>>> URL in a web browser: >>>> http://www.OpenLDAP.org/its/index.cgi?findid=3D9175 >>>> >>>> Please remember to retain your issue tracking number (ITS#9175) >>>> on any further messages you send to us regarding this report. If >>>> you don't then you'll just waste our time and yours because we >>>> won't be able to properly track the report. >>>> >>>> Please note that the Issue Tracking System is not intended to >>>> be used to seek help in the proper use of OpenLDAP Software. >>>> Such requests will be closed. >>>> >>>> OpenLDAP Software is user supported. >>>> http://www.OpenLDAP.org/support/ >>>> >>>> -------------- >>>> Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved. >>>> >>>> >>> >>> -- >>> >>> Lexi Haley (she/her/hers) >>> >>> Computer Scientist, System Tools, Advanced Technology Division >>> >>> Medical Information Technology, Inc. >>> >>> Office: 781-774-5156 | Mobile: 508-713-2499 >>> >>> lhaley(a)meditech.com >>> >>> MEDITECH Circle, Westwood, MA 02090 >>> >>> Main: 781-821-3000 | Fax: 781-821-2199 >>> >> >> >> -- >> >> Lexi Haley (she/her/hers) >> >> Computer Scientist, System Tools, Advanced Technology Division >> >> Medical Information Technology, Inc. >> >> Office: 781-774-5156 | Mobile: 508-713-2499 >> >> lhaley(a)meditech.com >> >> MEDITECH Circle, Westwood, MA 02090 >> >> Main: 781-821-3000 | Fax: 781-821-2199 >> > > > --=20 > > Lexi Haley (she/her/hers) > > Computer Scientist, System Tools, Advanced Technology Division > > Medical Information Technology, Inc. > > Office: 781-774-5156 | Mobile: 508-713-2499 > > lhaley(a)meditech.com > > MEDITECH Circle, Westwood, MA 02090 > > Main: 781-821-3000 | Fax: 781-821-2199 > > --=20 > <https://ehr.meditech.com/expanse>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= > =A0 =20 > <https://www.linkedin.com/company/meditech>=C2=A0 =20 > <https://twitter.com/MEDITECH>=C2=A0=C2=A0 > <https://www.facebook.com/Medite= chEHR> > > Subscribe=20 > <https://info.meditech.com/get-great-meditech-content?hsCtaTracking=3D864 > 29= > 9ec-5abf-4004-9c6d-2d051794101f%7Cc911be42-538a-4a48-8dca-a6d4001c6326>=20 > to receive emails from MEDITECH or to change email preferences. > > > --0000000000003b4d37059f1c0189 > Content-Type: text/html; charset="UTF-8" > Content-Transfer-Encoding: quoted-printable > > <div dir=3D"ltr">footnote:=C2=A0 In my first followup, I intended to > write= =C2=A0 "<span style=3D"color:rgb(0,0,0)">as I am quite > UNaccustomed to= working with the > data"</span><div>Cheers</div></div><br><div class=3D= > "gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, Feb 21, 2020 > at= 3:27 PM Lexi Haley <<a > href=3D"mailto:lhaley@meditech.com">lhaley@medit= ech.com</a>> > wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"= margin:0px > 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-lef= > t:1ex"><div dir=3D"ltr">FOUND THE ISSUE!=C2=A0 So - in GDB , while paused > i= n the "{mM}" processing that ber_scanf does (called > from=C2=A0lda= p_get_attribute_ber), I kept seeing the variable arguments > list not properl= y setting off --- and sure enough, digging in memory, > on the stack was 0x10= 0000000 ...=C2=A0 which was the cause of the > eventual segfault.<div><br></d= iv><div>Well, backtracking to the > ber_scanf call itself, I see a zero 0 whi= ch isn't cast to the > ber_len_t type, and as such, will only occupy 4 by= tes as a > sizeof=C2=A0int - instead of (( on my system 8, for sizeof (ber_le= > n_t).=C2=A0 So - the solution was just=C2=A0to cast the argument.=C2=A0 > So = that the=C2=A0cookie.off =3D va_arg( ap, ber_len_t ); will unpack > only byte= s we've intentionally sent it -- not garbage left > over.</div><div><br><= /div><div>So - the change suggested > is:</div><div><br></div><div><br></div>= <div><font > face=3D"monospace">diff --git a/libraries/libldap/getattr.c b/li= > braries/libldap/getattr.c<br>index 31784d765..0300ea574 100644<br>--- > a/lib= raries/libldap/getattr.c<br>+++ > b/libraries/libldap/getattr.c<br>@@ -147,7 = +147,7 @@ > ldap_get_attribute_ber( LDAP *ld, LDAPMessage *entry, BerElement = > *ber,<br><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /* > ski= p sequence, snarf attribute type */<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 > =C2=A0 = =C2=A0 =C2=A0 =C2=A0 tag =3D ber_scanf( ber, vals ? > "{mM}" : &quo= t;{mx}", attr, vals,<br>- =C2=A0 =C2=A0 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > &siz, 0 );<br>+ =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 &siz, (ber_len= _t)0 );<br>=C2=A0 =C2=A0 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if( tag = =3D=3D LBER_ERROR ) > {<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 > =C2=A0 =C2=A0 =C2=A0 rc =3D ld->ld_errno =3D LDAP_DECODING= > _ERROR;<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > }</font>= <br></div><div><br></div><div><br></div><div>I hope you can > take this hapha= zard issue submit, and do whatever is right with it - to > get this patch con= sidered.=C2=A0 > Thanks!</div><div><br></div><div><br></div></div><br><div cl= > ass=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, Feb 21, > 2= 020 at 1:06 PM Lexi Haley <<a href=3D"mailto:lhaley@meditech.com" > target= =3D"_blank">lhaley(a)meditech.com</a>> > wrote:<br></div><blockquote class= =3D"gmail_quote" style=3D"margin:0px > 0px 0px 0.8ex;border-left:1px solid rg= > b(204,204,204);padding-left:1ex"><div dir=3D"ltr">continuing notes - as I > a= m quite accustomed to working with the data structures and processes > for LD= AP - my hacky fudge was just that - and also useless.=C2=A0 By > bailing out = at that point, ldapsearch doesn't list the tag=3Dvalue > results.=C2=A0 I= am continuing to dig around > ...<div><br></div><div>Lexi</div></div><br><di= v > class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, Feb 2= > 0, 2020 at 3:09 PM <<a href=3D"mailto:openldap-its@openldap.org" > target= =3D"_blank">openldap-its(a)openldap.org</a>> > wrote:<br></div><blockquote c= lass=3D"gmail_quote" style=3D"margin:0px > 0px 0px 0.8ex;border-left:1px soli= d > rgb(204,204,204);padding-left:1ex"><br> > *** THIS IS AN AUTOMATICALLY GENERATED REPLY ***<br> > <br> > Thanks for your report to the OpenLDAP Issue Tracking System.=C2=A0 > Your<br= >> > report has been assigned the tracking number ITS#9175.<br> > <br> > One of our support engineers will look at your report in due course.<br> > Note that this may take some time because our support engineers<br> > are volunteers.=C2=A0 They only work on OpenLDAP when they have spare<br> > time.<br> > <br> > If you need to provide additional information in regards to your<br> > issue report, you may do so by replying to this message.=C2=A0 Note > that<br= >> > any mail sent to <a href=3D"mailto:openldap-its@openldap.org" > target=3D"_bl= ank">openldap-its(a)openldap.org</a> with (ITS#9175)<br> > in the subject will automatically be attached to the issue report.<br> > <br> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 mailto:<a > href=3D"mailto:openldap-its@openldap.= org" > target=3D"_blank">openldap-its(a)openldap.org</a>?subject=3D(ITS#9175)<b= r> > <br> > You may follow the progress of this report by loading the following<br> > URL in a web browser:<br> > =C2=A0 =C2=A0 <a > href=3D"http://www.OpenLDAP.org/its/index.cgi?findid=3D917= 5" > rel=3D"noreferrer" target=3D"_blank">http://www.OpenLDAP.org/its/index.c= > gi?findid=3D9175</a><br> > <br> > Please remember to retain your issue tracking number (ITS#9175)<br> > on any further messages you send to us regarding this report.=C2=A0 If<br> > you don't then you'll just waste our time and yours because we<br> > won't be able to properly track the report.<br> > <br> > Please note that the Issue Tracking System is not intended to<br> > be used to seek help in the proper use of OpenLDAP Software.<br> > Such requests will be closed.<br> > <br> > OpenLDAP Software is user supported.<br> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 <a href=3D"http://www.OpenLDAP.org/support/" > re= l=3D"noreferrer" > target=3D"_blank">http://www.OpenLDAP.org/support/</a><br> <br> > --------------<br> > Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved.<br> > <br> > </blockquote></div><br clear=3D"all"><div><br></div>-- <br><div > dir=3D"ltr"= >> <div dir=3D"ltr"><div><div dir=3D"ltr"><div><div dir=3D"ltr"><p >> dir=3D"ltr= > " > style=3D"color:rgb(80,0,80);line-height:1.38;margin-top:0pt;margin-bottom= > :0pt"><span > style=3D"font-size:13pt;font-family:Verdana;color:rgb(0,0,0);fo= > nt-weight:700;vertical-align:baseline;white-space:pre-wrap">Lexi Haley > </sp= an><span > style=3D"color:rgb(102,102,102);font-family:Verdana;font-size:13.3= > 333px;white-space:pre-wrap">(she/her/hers)</span></p><p dir=3D"ltr" style= > =3D"color:rgb(80,0,80);line-height:1.38;margin-top:0pt;margin-bottom:0pt" > ><= span > style=3D"font-size:10pt;font-family:Verdana;color:rgb(102,102,102);ver= > tical-align:baseline;white-space:pre-wrap">Computer Scientist, System > Tools= , Advanced Technology Division</span></p><p dir=3D"ltr" > style=3D"color:rgb(= > 80,0,80);line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span > style=3D"= > font-size:10pt;font-family:Verdana;color:rgb(102,102,102);vertical-align: > ba= seline;white-space:pre-wrap">Medical Information Technology, > Inc.</span></p= >> <p dir=3D"ltr" >> style=3D"color:rgb(80,0,80);line-height:1.38;margin-top:0pt= > ;margin-bottom:0pt"><span > style=3D"font-size:10pt;font-family:Verdana;color= > :rgb(102,102,102);vertical-align:baseline;white-space:pre-wrap">Office: > 781= -774-5156 | Mobile: 508-713-2499</span></p><p > style=3D"color:rgb(80,0,80);l= > ine-height:1.38;margin-top:0pt;margin-bottom:0pt"><font > face=3D"Verdana"><s= pan > style=3D"font-size:13.3333px;white-space:pre-wrap"><a href=3D"mailto:lh= > aley(a)meditech.com" > target=3D"_blank">lhaley(a)meditech.com</a></span></font><= /p><p > dir=3D"ltr" style=3D"color:rgb(80,0,80);line-height:1.38;margin-top:0= > pt;margin-bottom:0pt"><span > style=3D"font-size:10pt;font-family:Verdana;col= > or:rgb(102,102,102);vertical-align:baseline;white-space:pre-wrap">MEDITEC > H = Circle, Westwood, MA 02090</span></p><p dir=3D"ltr" > style=3D"color:rgb(80,0= > ,80);line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span > style=3D"font= > -size:10pt;font-family:Verdana;color:rgb(102,102,102);vertical-align:base > li= ne;white-space:pre-wrap">Main: 781-821-3000 | Fax: > 781-821-2199</span></p><= /div></div></div></div></div></div> > </blockquote></div><br clear=3D"all"><div><br></div>-- <br><div > dir=3D"ltr"= >> <div dir=3D"ltr"><div><div dir=3D"ltr"><div><div dir=3D"ltr"><p >> dir=3D"ltr= > " > style=3D"color:rgb(80,0,80);line-height:1.38;margin-top:0pt;margin-bottom= > :0pt"><span > style=3D"font-size:13pt;font-family:Verdana;color:rgb(0,0,0);fo= > nt-weight:700;vertical-align:baseline;white-space:pre-wrap">Lexi Haley > </sp= an><span > style=3D"color:rgb(102,102,102);font-family:Verdana;font-size:13.3= > 333px;white-space:pre-wrap">(she/her/hers)</span></p><p dir=3D"ltr" style= > =3D"color:rgb(80,0,80);line-height:1.38;margin-top:0pt;margin-bottom:0pt" > ><= span > style=3D"font-size:10pt;font-family:Verdana;color:rgb(102,102,102);ver= > tical-align:baseline;white-space:pre-wrap">Computer Scientist, System > Tools= , Advanced Technology Division</span></p><p dir=3D"ltr" > style=3D"color:rgb(= > 80,0,80);line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span > style=3D"= > font-size:10pt;font-family:Verdana;color:rgb(102,102,102);vertical-align: > ba= seline;white-space:pre-wrap">Medical Information Technology, > Inc.</span></p= >> <p dir=3D"ltr" >> style=3D"color:rgb(80,0,80);line-height:1.38;margin-top:0pt= > ;margin-bottom:0pt"><span > style=3D"font-size:10pt;font-family:Verdana;color= > :rgb(102,102,102);vertical-align:baseline;white-space:pre-wrap">Office: > 781= -774-5156 | Mobile: 508-713-2499</span></p><p > style=3D"color:rgb(80,0,80);l= > ine-height:1.38;margin-top:0pt;margin-bottom:0pt"><font > face=3D"Verdana"><s= pan > style=3D"font-size:13.3333px;white-space:pre-wrap"><a href=3D"mailto:lh= > aley(a)meditech.com" > target=3D"_blank">lhaley(a)meditech.com</a></span></font><= /p><p > dir=3D"ltr" style=3D"color:rgb(80,0,80);line-height:1.38;margin-top:0= > pt;margin-bottom:0pt"><span > style=3D"font-size:10pt;font-family:Verdana;col= > or:rgb(102,102,102);vertical-align:baseline;white-space:pre-wrap">MEDITEC > H = Circle, Westwood, MA 02090</span></p><p dir=3D"ltr" > style=3D"color:rgb(80,0= > ,80);line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span > style=3D"font= > -size:10pt;font-family:Verdana;color:rgb(102,102,102);vertical-align:base > li= ne;white-space:pre-wrap">Main: 781-821-3000 | Fax: > 781-821-2199</span></p><= /div></div></div></div></div></div> > </blockquote></div><br clear=3D"all"><div><br></div>-- <br><div > dir=3D"ltr"= class=3D"gmail_signature"><div dir=3D"ltr"><div><div > dir=3D"ltr"><div><div= dir=3D"ltr"><p dir=3D"ltr" > style=3D"color:rgb(80,0,80);line-height:1.38;ma= > rgin-top:0pt;margin-bottom:0pt"><span > style=3D"font-size:13pt;font-family:V= > erdana;color:rgb(0,0,0);font-weight:700;vertical-align:baseline;white-spa > ce= :pre-wrap">Lexi Haley </span><span > style=3D"color:rgb(102,102,102);font-fam= > ily:Verdana;font-size:13.3333px;white-space:pre-wrap">(she/her/hers)</spa > n>= </p><p dir=3D"ltr" > style=3D"color:rgb(80,0,80);line-height:1.38;margin-top:= > 0pt;margin-bottom:0pt"><span > style=3D"font-size:10pt;font-family:Verdana;co= > lor:rgb(102,102,102);vertical-align:baseline;white-space:pre-wrap">Comput > er= Scientist, System Tools, Advanced Technology Division</span></p><p > dir=3D"= ltr" > style=3D"color:rgb(80,0,80);line-height:1.38;margin-top:0pt;margin-bot= > tom:0pt"><span > style=3D"font-size:10pt;font-family:Verdana;color:rgb(102,10= > 2,102);vertical-align:baseline;white-space:pre-wrap">Medical Information > Te= chnology, Inc.</span></p><p dir=3D"ltr" > style=3D"color:rgb(80,0,80);line-he= > ight:1.38;margin-top:0pt;margin-bottom:0pt"><span > style=3D"font-size:10pt;f= > ont-family:Verdana;color:rgb(102,102,102);vertical-align:baseline;white-s > pa= ce:pre-wrap">Office: 781-774-5156 | Mobile: 508-713-2499</span></p><p > style= > =3D"color:rgb(80,0,80);line-height:1.38;margin-top:0pt;margin-bottom:0pt" > ><= font face=3D"Verdana"><span > style=3D"font-size:13.3333px;white-space:pre-wr= ap"><a > href=3D"mailto:lhaley@meditech.com" target=3D"_blank">lhaley@meditec= > h.com</a></span></font></p><p dir=3D"ltr" > style=3D"color:rgb(80,0,80);line-= > height:1.38;margin-top:0pt;margin-bottom:0pt"><span > style=3D"font-size:10pt= > ;font-family:Verdana;color:rgb(102,102,102);vertical-align:baseline;white > -s= pace:pre-wrap">MEDITECH Circle, Westwood, MA 02090</span></p><p > dir=3D"ltr"= > style=3D"color:rgb(80,0,80);line-height:1.38;margin-top:0pt;margin-botto > m:= 0pt"><span > style=3D"font-size:10pt;font-family:Verdana;color:rgb(102,102,10= > 2);vertical-align:baseline;white-space:pre-wrap">Main: 781-821-3000 | > Fax: = 781-821-2199</span></p></div></div></div></div></div></div> > > <br> > <a href=3D"https://ehr.meditech.com/expanse" target=3D"_blank"><img > src=3D"= > https://home.meditech.com/en/d/home/images/meditechemailsignaturelogo2018 > ex= panse.jpg"></a><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <a > href=3D"ht= tps://www.linkedin.com/company/meditech" > target=3D"_blank"><img src=3D"http= > s://home.meditech.com/en/d/home/images/emailsignaturelinkedin20pixels.gif > " = style=3D"font-size:1.3em"></a><span style=3D"font-size:1.3em">=C2=A0 > </span= >> <a href=3D"https://twitter.com/MEDITECH" target=3D"_blank"><img >> src=3D"htt= > ps://home.meditech.com/en/d/home/images/emailsignaturetwitter20pixels.gif > " = style=3D"font-size:1.3em"></a><span > style=3D"font-size:1.3em">=C2=A0=C2=A0<= /span><a > href=3D"https://www.facebook.com/MeditechEHR" target=3D"_blank"><i= mg > src=3D"https://home.meditech.com/en/d/home/images/emailsignaturefacebook= > 20pixels.gif" style=3D"font-size:1.3em"></a></div><div><div><a > href=3D"http= > s://info.meditech.com/get-great-meditech-content?hsCtaTracking=3D864299ec > -5= abf-4004-9c6d-2d051794101f%7Cc911be42-538a-4a48-8dca-a6d4001c6326" > target= =3D"_blank"><span > style=3D"font-size:10pt;font-family:Verdana;color:rgb(17,= > 85,204);vertical-align:baseline;white-space:pre-wrap">Subscribe</span></a > ><= span > style=3D"font-size:10pt;font-family:Verdana;vertical-align:baseline;wh= > ite-space:pre-wrap"> </span><span > style=3D"font-size:10pt;font-family:Verda= > na;color:rgb(102,102,102);vertical-align:baseline;white-space:pre-wrap">t > o = receive emails from MEDITECH or to change email > preferences.</span></div></= div> > --0000000000003b4d37059f1c0189-- > > > -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#9175) ldapsearch segfault
by lhaley＠meditech.com 21 Feb '20

21 Feb '20

--0000000000003b4d37059f1c0189 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable footnote: In my first followup, I intended to write "as I am quite UNaccustomed to working with the data" Cheers On Fri, Feb 21, 2020 at 3:27 PM Lexi Haley <lhaley(a)meditech.com> wrote: > FOUND THE ISSUE! So - in GDB , while paused in the "{mM}" processing tha= t > ber_scanf does (called from ldap_get_attribute_ber), I kept seeing the > variable arguments list not properly setting off --- and sure enough, > digging in memory, on the stack was 0x100000000 ... which was the cause = of > the eventual segfault. > > Well, backtracking to the ber_scanf call itself, I see a zero 0 which > isn't cast to the ber_len_t type, and as such, will only occupy 4 bytes a= s > a sizeof int - instead of (( on my system 8, for sizeof (ber_len_t). So = - > the solution was just to cast the argument. So that the cookie.off =3D > va_arg( ap, ber_len_t ); will unpack only bytes we've intentionally sent = it > -- not garbage left over. > > So - the change suggested is: > > > diff --git a/libraries/libldap/getattr.c b/libraries/libldap/getattr.c > index 31784d765..0300ea574 100644 > --- a/libraries/libldap/getattr.c > +++ b/libraries/libldap/getattr.c > @@ -147,7 +147,7 @@ ldap_get_attribute_ber( LDAP *ld, LDAPMessage *entry, > BerElement *ber, > > /* skip sequence, snarf attribute type */ > tag =3D ber_scanf( ber, vals ? "{mM}" : "{mx}", attr, val= s, > - &siz, 0 ); > + &siz, (ber_len_t)0 ); > if( tag =3D=3D LBER_ERROR ) { > rc =3D ld->ld_errno =3D LDAP_DECODING_ERROR; > } > > > I hope you can take this haphazard issue submit, and do whatever is right > with it - to get this patch considered. Thanks! > > > > On Fri, Feb 21, 2020 at 1:06 PM Lexi Haley <lhaley(a)meditech.com> wrote: > >> continuing notes - as I am quite accustomed to working with the data >> structures and processes for LDAP - my hacky fudge was just that - and a= lso >> useless. By bailing out at that point, ldapsearch doesn't list the >> tag=3Dvalue results. I am continuing to dig around ... >> >> Lexi >> >> On Thu, Feb 20, 2020 at 3:09 PM <openldap-its(a)openldap.org> wrote: >> >>> >>> *** THIS IS AN AUTOMATICALLY GENERATED REPLY *** >>> >>> Thanks for your report to the OpenLDAP Issue Tracking System. Your >>> report has been assigned the tracking number ITS#9175. >>> >>> One of our support engineers will look at your report in due course. >>> Note that this may take some time because our support engineers >>> are volunteers. They only work on OpenLDAP when they have spare >>> time. >>> >>> If you need to provide additional information in regards to your >>> issue report, you may do so by replying to this message. Note that >>> any mail sent to openldap-its(a)openldap.org with (ITS#9175) >>> in the subject will automatically be attached to the issue report. >>> >>> mailto:openldap-its@openldap.org?subject=3D(ITS#9175) >>> >>> You may follow the progress of this report by loading the following >>> URL in a web browser: >>> http://www.OpenLDAP.org/its/index.cgi?findid=3D9175 >>> >>> Please remember to retain your issue tracking number (ITS#9175) >>> on any further messages you send to us regarding this report. If >>> you don't then you'll just waste our time and yours because we >>> won't be able to properly track the report. >>> >>> Please note that the Issue Tracking System is not intended to >>> be used to seek help in the proper use of OpenLDAP Software. >>> Such requests will be closed. >>> >>> OpenLDAP Software is user supported. >>> http://www.OpenLDAP.org/support/ >>> >>> -------------- >>> Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved. >>> >>> >> >> -- >> >> Lexi Haley (she/her/hers) >> >> Computer Scientist, System Tools, Advanced Technology Division >> >> Medical Information Technology, Inc. >> >> Office: 781-774-5156 | Mobile: 508-713-2499 >> >> lhaley(a)meditech.com >> >> MEDITECH Circle, Westwood, MA 02090 >> >> Main: 781-821-3000 | Fax: 781-821-2199 >> > > > -- > > Lexi Haley (she/her/hers) > > Computer Scientist, System Tools, Advanced Technology Division > > Medical Information Technology, Inc. > > Office: 781-774-5156 | Mobile: 508-713-2499 > > lhaley(a)meditech.com > > MEDITECH Circle, Westwood, MA 02090 > > Main: 781-821-3000 | Fax: 781-821-2199 > --=20 Lexi Haley (she/her/hers) Computer Scientist, System Tools, Advanced Technology Division Medical Information Technology, Inc. Office: 781-774-5156 | Mobile: 508-713-2499 lhaley(a)meditech.com MEDITECH Circle, Westwood, MA 02090 Main: 781-821-3000 | Fax: 781-821-2199 --=20 <https://ehr.meditech.com/expanse>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =20 <https://www.linkedin.com/company/meditech>=C2=A0 =20 <https://twitter.com/MEDITECH>=C2=A0=C2=A0 <https://www.facebook.com/Medite= chEHR> Subscribe=20 <https://info.meditech.com/get-great-meditech-content?hsCtaTracking=3D86429= 9ec-5abf-4004-9c6d-2d051794101f%7Cc911be42-538a-4a48-8dca-a6d4001c6326>=20 to receive emails from MEDITECH or to change email preferences. --0000000000003b4d37059f1c0189 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">footnote:=C2=A0 In my first followup, I intended to write= =C2=A0 "<span style=3D"color:rgb(0,0,0)">as I am quite UNaccustomed to= working with the data"</span><div>Cheers</div></div><br><div class=3D= "gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, Feb 21, 2020 at= 3:27 PM Lexi Haley <<a href=3D"mailto:lhaley@meditech.com">lhaley@medit= ech.com</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"= margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-lef= t:1ex"><div dir=3D"ltr">FOUND THE ISSUE!=C2=A0 So - in GDB , while paused i= n the "{mM}" processing that ber_scanf does (called from=C2=A0lda= p_get_attribute_ber), I kept seeing the variable arguments list not properl= y setting off --- and sure enough, digging in memory, on the stack was 0x10= 0000000 ...=C2=A0 which was the cause of the eventual segfault.<div><br></d= iv><div>Well, backtracking to the ber_scanf call itself, I see a zero 0 whi= ch isn't cast to the ber_len_t type, and as such, will only occupy 4 by= tes as a sizeof=C2=A0int - instead of (( on my system 8, for sizeof (ber_le= n_t).=C2=A0 So - the solution was just=C2=A0to cast the argument.=C2=A0 So = that the=C2=A0cookie.off =3D va_arg( ap, ber_len_t ); will unpack only byte= s we've intentionally sent it -- not garbage left over.</div><div><br><= /div><div>So - the change suggested is:</div><div><br></div><div><br></div>= <div><font face=3D"monospace">diff --git a/libraries/libldap/getattr.c b/li= braries/libldap/getattr.c<br>index 31784d765..0300ea574 100644<br>--- a/lib= raries/libldap/getattr.c<br>+++ b/libraries/libldap/getattr.c<br>@@ -147,7 = +147,7 @@ ldap_get_attribute_ber( LDAP *ld, LDAPMessage *entry, BerElement = *ber,<br><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /* ski= p sequence, snarf attribute type */<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 tag =3D ber_scanf( ber, vals ? "{mM}" : &quo= t;{mx}", attr, vals,<br>- =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 &siz, 0 );<br>+ =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 &siz, (ber_len= _t)0 );<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if( tag = =3D=3D LBER_ERROR ) {<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 rc =3D ld->ld_errno =3D LDAP_DECODING= _ERROR;<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }</font>= <br></div><div><br></div><div><br></div><div>I hope you can take this hapha= zard issue submit, and do whatever is right with it - to get this patch con= sidered.=C2=A0 Thanks!</div><div><br></div><div><br></div></div><br><div cl= ass=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, Feb 21, 2= 020 at 1:06 PM Lexi Haley <<a href=3D"mailto:lhaley@meditech.com" target= =3D"_blank">lhaley(a)meditech.com</a>> wrote:<br></div><blockquote class= =3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg= b(204,204,204);padding-left:1ex"><div dir=3D"ltr">continuing notes - as I a= m quite accustomed to working with the data structures and processes for LD= AP - my hacky fudge was just that - and also useless.=C2=A0 By bailing out = at that point, ldapsearch doesn't list the tag=3Dvalue results.=C2=A0 I= am continuing to dig around ...<div><br></div><div>Lexi</div></div><br><di= v class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, Feb 2= 0, 2020 at 3:09 PM <<a href=3D"mailto:openldap-its@openldap.org" target= =3D"_blank">openldap-its(a)openldap.org</a>> wrote:<br></div><blockquote c= lass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px soli= d rgb(204,204,204);padding-left:1ex"><br> *** THIS IS AN AUTOMATICALLY GENERATED REPLY ***<br> <br> Thanks for your report to the OpenLDAP Issue Tracking System.=C2=A0 Your<br= > report has been assigned the tracking number ITS#9175.<br> <br> One of our support engineers will look at your report in due course.<br> Note that this may take some time because our support engineers<br> are volunteers.=C2=A0 They only work on OpenLDAP when they have spare<br> time.<br> <br> If you need to provide additional information in regards to your<br> issue report, you may do so by replying to this message.=C2=A0 Note that<br= > any mail sent to <a href=3D"mailto:openldap-its@openldap.org" target=3D"_bl= ank">openldap-its(a)openldap.org</a> with (ITS#9175)<br> in the subject will automatically be attached to the issue report.<br> <br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 mailto:<a href=3D"mailto:openldap-its@openldap.= org" target=3D"_blank">openldap-its(a)openldap.org</a>?subject=3D(ITS#9175)<b= r> <br> You may follow the progress of this report by loading the following<br> URL in a web browser:<br> =C2=A0 =C2=A0 <a href=3D"http://www.OpenLDAP.org/its/index.cgi?findid=3D917= 5" rel=3D"noreferrer" target=3D"_blank">http://www.OpenLDAP.org/its/index.c= gi?findid=3D9175</a><br> <br> Please remember to retain your issue tracking number (ITS#9175)<br> on any further messages you send to us regarding this report.=C2=A0 If<br> you don't then you'll just waste our time and yours because we<br> won't be able to properly track the report.<br> <br> Please note that the Issue Tracking System is not intended to<br> be used to seek help in the proper use of OpenLDAP Software.<br> Such requests will be closed.<br> <br> OpenLDAP Software is user supported.<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 <a href=3D"http://www.OpenLDAP.org/support/" re= l=3D"noreferrer" target=3D"_blank">http://www.OpenLDAP.org/support/</a><br> <br> --------------<br> Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved.<br> <br> </blockquote></div><br clear=3D"all"><div><br></div>-- <br><div dir=3D"ltr"= ><div dir=3D"ltr"><div><div dir=3D"ltr"><div><div dir=3D"ltr"><p dir=3D"ltr= " style=3D"color:rgb(80,0,80);line-height:1.38;margin-top:0pt;margin-bottom= :0pt"><span style=3D"font-size:13pt;font-family:Verdana;color:rgb(0,0,0);fo= nt-weight:700;vertical-align:baseline;white-space:pre-wrap">Lexi Haley </sp= an><span style=3D"color:rgb(102,102,102);font-family:Verdana;font-size:13.3= 333px;white-space:pre-wrap">(she/her/hers)</span></p><p dir=3D"ltr" style= =3D"color:rgb(80,0,80);line-height:1.38;margin-top:0pt;margin-bottom:0pt"><= span style=3D"font-size:10pt;font-family:Verdana;color:rgb(102,102,102);ver= tical-align:baseline;white-space:pre-wrap">Computer Scientist, System Tools= , Advanced Technology Division</span></p><p dir=3D"ltr" style=3D"color:rgb(= 80,0,80);line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style=3D"= font-size:10pt;font-family:Verdana;color:rgb(102,102,102);vertical-align:ba= seline;white-space:pre-wrap">Medical Information Technology, Inc.</span></p= ><p dir=3D"ltr" style=3D"color:rgb(80,0,80);line-height:1.38;margin-top:0pt= ;margin-bottom:0pt"><span style=3D"font-size:10pt;font-family:Verdana;color= :rgb(102,102,102);vertical-align:baseline;white-space:pre-wrap">Office: 781= -774-5156 | Mobile: 508-713-2499</span></p><p style=3D"color:rgb(80,0,80);l= ine-height:1.38;margin-top:0pt;margin-bottom:0pt"><font face=3D"Verdana"><s= pan style=3D"font-size:13.3333px;white-space:pre-wrap"><a href=3D"mailto:lh= aley(a)meditech.com" target=3D"_blank">lhaley(a)meditech.com</a></span></font><= /p><p dir=3D"ltr" style=3D"color:rgb(80,0,80);line-height:1.38;margin-top:0= pt;margin-bottom:0pt"><span style=3D"font-size:10pt;font-family:Verdana;col= or:rgb(102,102,102);vertical-align:baseline;white-space:pre-wrap">MEDITECH = Circle, Westwood, MA 02090</span></p><p dir=3D"ltr" style=3D"color:rgb(80,0= ,80);line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style=3D"font= -size:10pt;font-family:Verdana;color:rgb(102,102,102);vertical-align:baseli= ne;white-space:pre-wrap">Main: 781-821-3000 | Fax: 781-821-2199</span></p><= /div></div></div></div></div></div> </blockquote></div><br clear=3D"all"><div><br></div>-- <br><div dir=3D"ltr"= ><div dir=3D"ltr"><div><div dir=3D"ltr"><div><div dir=3D"ltr"><p dir=3D"ltr= " style=3D"color:rgb(80,0,80);line-height:1.38;margin-top:0pt;margin-bottom= :0pt"><span style=3D"font-size:13pt;font-family:Verdana;color:rgb(0,0,0);fo= nt-weight:700;vertical-align:baseline;white-space:pre-wrap">Lexi Haley </sp= an><span style=3D"color:rgb(102,102,102);font-family:Verdana;font-size:13.3= 333px;white-space:pre-wrap">(she/her/hers)</span></p><p dir=3D"ltr" style= =3D"color:rgb(80,0,80);line-height:1.38;margin-top:0pt;margin-bottom:0pt"><= span style=3D"font-size:10pt;font-family:Verdana;color:rgb(102,102,102);ver= tical-align:baseline;white-space:pre-wrap">Computer Scientist, System Tools= , Advanced Technology Division</span></p><p dir=3D"ltr" style=3D"color:rgb(= 80,0,80);line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style=3D"= font-size:10pt;font-family:Verdana;color:rgb(102,102,102);vertical-align:ba= seline;white-space:pre-wrap">Medical Information Technology, Inc.</span></p= ><p dir=3D"ltr" style=3D"color:rgb(80,0,80);line-height:1.38;margin-top:0pt= ;margin-bottom:0pt"><span style=3D"font-size:10pt;font-family:Verdana;color= :rgb(102,102,102);vertical-align:baseline;white-space:pre-wrap">Office: 781= -774-5156 | Mobile: 508-713-2499</span></p><p style=3D"color:rgb(80,0,80);l= ine-height:1.38;margin-top:0pt;margin-bottom:0pt"><font face=3D"Verdana"><s= pan style=3D"font-size:13.3333px;white-space:pre-wrap"><a href=3D"mailto:lh= aley(a)meditech.com" target=3D"_blank">lhaley(a)meditech.com</a></span></font><= /p><p dir=3D"ltr" style=3D"color:rgb(80,0,80);line-height:1.38;margin-top:0= pt;margin-bottom:0pt"><span style=3D"font-size:10pt;font-family:Verdana;col= or:rgb(102,102,102);vertical-align:baseline;white-space:pre-wrap">MEDITECH = Circle, Westwood, MA 02090</span></p><p dir=3D"ltr" style=3D"color:rgb(80,0= ,80);line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style=3D"font= -size:10pt;font-family:Verdana;color:rgb(102,102,102);vertical-align:baseli= ne;white-space:pre-wrap">Main: 781-821-3000 | Fax: 781-821-2199</span></p><= /div></div></div></div></div></div> </blockquote></div><br clear=3D"all"><div><br></div>-- <br><div dir=3D"ltr"= class=3D"gmail_signature"><div dir=3D"ltr"><div><div dir=3D"ltr"><div><div= dir=3D"ltr"><p dir=3D"ltr" style=3D"color:rgb(80,0,80);line-height:1.38;ma= rgin-top:0pt;margin-bottom:0pt"><span style=3D"font-size:13pt;font-family:V= erdana;color:rgb(0,0,0);font-weight:700;vertical-align:baseline;white-space= :pre-wrap">Lexi Haley </span><span style=3D"color:rgb(102,102,102);font-fam= ily:Verdana;font-size:13.3333px;white-space:pre-wrap">(she/her/hers)</span>= </p><p dir=3D"ltr" style=3D"color:rgb(80,0,80);line-height:1.38;margin-top:= 0pt;margin-bottom:0pt"><span style=3D"font-size:10pt;font-family:Verdana;co= lor:rgb(102,102,102);vertical-align:baseline;white-space:pre-wrap">Computer= Scientist, System Tools, Advanced Technology Division</span></p><p dir=3D"= ltr" style=3D"color:rgb(80,0,80);line-height:1.38;margin-top:0pt;margin-bot= tom:0pt"><span style=3D"font-size:10pt;font-family:Verdana;color:rgb(102,10= 2,102);vertical-align:baseline;white-space:pre-wrap">Medical Information Te= chnology, Inc.</span></p><p dir=3D"ltr" style=3D"color:rgb(80,0,80);line-he= ight:1.38;margin-top:0pt;margin-bottom:0pt"><span style=3D"font-size:10pt;f= ont-family:Verdana;color:rgb(102,102,102);vertical-align:baseline;white-spa= ce:pre-wrap">Office: 781-774-5156 | Mobile: 508-713-2499</span></p><p style= =3D"color:rgb(80,0,80);line-height:1.38;margin-top:0pt;margin-bottom:0pt"><= font face=3D"Verdana"><span style=3D"font-size:13.3333px;white-space:pre-wr= ap"><a href=3D"mailto:lhaley@meditech.com" target=3D"_blank">lhaley@meditec= h.com</a></span></font></p><p dir=3D"ltr" style=3D"color:rgb(80,0,80);line-= height:1.38;margin-top:0pt;margin-bottom:0pt"><span style=3D"font-size:10pt= ;font-family:Verdana;color:rgb(102,102,102);vertical-align:baseline;white-s= pace:pre-wrap">MEDITECH Circle, Westwood, MA 02090</span></p><p dir=3D"ltr"= style=3D"color:rgb(80,0,80);line-height:1.38;margin-top:0pt;margin-bottom:= 0pt"><span style=3D"font-size:10pt;font-family:Verdana;color:rgb(102,102,10= 2);vertical-align:baseline;white-space:pre-wrap">Main: 781-821-3000 | Fax: = 781-821-2199</span></p></div></div></div></div></div></div> <br> <a href=3D"https://ehr.meditech.com/expanse" target=3D"_blank"><img src=3D"= https://home.meditech.com/en/d/home/images/meditechemailsignaturelogo2018ex= panse.jpg"></a><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <a href=3D"ht= tps://www.linkedin.com/company/meditech" target=3D"_blank"><img src=3D"http= s://home.meditech.com/en/d/home/images/emailsignaturelinkedin20pixels.gif" = style=3D"font-size:1.3em"></a><span style=3D"font-size:1.3em">=C2=A0 </span= ><a href=3D"https://twitter.com/MEDITECH" target=3D"_blank"><img src=3D"htt= ps://home.meditech.com/en/d/home/images/emailsignaturetwitter20pixels.gif" = style=3D"font-size:1.3em"></a><span style=3D"font-size:1.3em">=C2=A0=C2=A0<= /span><a href=3D"https://www.facebook.com/MeditechEHR" target=3D"_blank"><i= mg src=3D"https://home.meditech.com/en/d/home/images/emailsignaturefacebook= 20pixels.gif" style=3D"font-size:1.3em"></a></div><div><div><a href=3D"http= s://info.meditech.com/get-great-meditech-content?hsCtaTracking=3D864299ec-5= abf-4004-9c6d-2d051794101f%7Cc911be42-538a-4a48-8dca-a6d4001c6326" target= =3D"_blank"><span style=3D"font-size:10pt;font-family:Verdana;color:rgb(17,= 85,204);vertical-align:baseline;white-space:pre-wrap">Subscribe</span></a><= span style=3D"font-size:10pt;font-family:Verdana;vertical-align:baseline;wh= ite-space:pre-wrap"> </span><span style=3D"font-size:10pt;font-family:Verda= na;color:rgb(102,102,102);vertical-align:baseline;white-space:pre-wrap">to = receive emails from MEDITECH or to change email preferences.</span></div></= div> --0000000000003b4d37059f1c0189--

1 0

Re: (ITS#9175) ldapsearch segfault
by lhaley＠meditech.com 21 Feb '20

21 Feb '20

--00000000000062d6a8059f1bda34 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable FOUND THE ISSUE! So - in GDB , while paused in the "{mM}" processing that ber_scanf does (called from ldap_get_attribute_ber), I kept seeing the variable arguments list not properly setting off --- and sure enough, digging in memory, on the stack was 0x100000000 ... which was the cause of the eventual segfault. Well, backtracking to the ber_scanf call itself, I see a zero 0 which isn't cast to the ber_len_t type, and as such, will only occupy 4 bytes as a sizeof int - instead of (( on my system 8, for sizeof (ber_len_t). So - the solution was just to cast the argument. So that the cookie.off =3D va_arg( ap, ber_len_t ); will unpack only bytes we've intentionally sent it -- not garbage left over. So - the change suggested is: diff --git a/libraries/libldap/getattr.c b/libraries/libldap/getattr.c index 31784d765..0300ea574 100644 --- a/libraries/libldap/getattr.c +++ b/libraries/libldap/getattr.c @@ -147,7 +147,7 @@ ldap_get_attribute_ber( LDAP *ld, LDAPMessage *entry, BerElement *ber, /* skip sequence, snarf attribute type */ tag =3D ber_scanf( ber, vals ? "{mM}" : "{mx}", attr, vals, - &siz, 0 ); + &siz, (ber_len_t)0 ); if( tag =3D=3D LBER_ERROR ) { rc =3D ld->ld_errno =3D LDAP_DECODING_ERROR; } I hope you can take this haphazard issue submit, and do whatever is right with it - to get this patch considered. Thanks! On Fri, Feb 21, 2020 at 1:06 PM Lexi Haley <lhaley(a)meditech.com> wrote: > continuing notes - as I am quite accustomed to working with the data > structures and processes for LDAP - my hacky fudge was just that - and al= so > useless. By bailing out at that point, ldapsearch doesn't list the > tag=3Dvalue results. I am continuing to dig around ... > > Lexi > > On Thu, Feb 20, 2020 at 3:09 PM <openldap-its(a)openldap.org> wrote: > >> >> *** THIS IS AN AUTOMATICALLY GENERATED REPLY *** >> >> Thanks for your report to the OpenLDAP Issue Tracking System. Your >> report has been assigned the tracking number ITS#9175. >> >> One of our support engineers will look at your report in due course. >> Note that this may take some time because our support engineers >> are volunteers. They only work on OpenLDAP when they have spare >> time. >> >> If you need to provide additional information in regards to your >> issue report, you may do so by replying to this message. Note that >> any mail sent to openldap-its(a)openldap.org with (ITS#9175) >> in the subject will automatically be attached to the issue report. >> >> mailto:openldap-its@openldap.org?subject=3D(ITS#9175) >> >> You may follow the progress of this report by loading the following >> URL in a web browser: >> http://www.OpenLDAP.org/its/index.cgi?findid=3D9175 >> >> Please remember to retain your issue tracking number (ITS#9175) >> on any further messages you send to us regarding this report. If >> you don't then you'll just waste our time and yours because we >> won't be able to properly track the report. >> >> Please note that the Issue Tracking System is not intended to >> be used to seek help in the proper use of OpenLDAP Software. >> Such requests will be closed. >> >> OpenLDAP Software is user supported. >> http://www.OpenLDAP.org/support/ >> >> -------------- >> Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved. >> >> > > -- > > Lexi Haley (she/her/hers) > > Computer Scientist, System Tools, Advanced Technology Division > > Medical Information Technology, Inc. > > Office: 781-774-5156 | Mobile: 508-713-2499 > > lhaley(a)meditech.com > > MEDITECH Circle, Westwood, MA 02090 > > Main: 781-821-3000 | Fax: 781-821-2199 > --=20 Lexi Haley (she/her/hers) Computer Scientist, System Tools, Advanced Technology Division Medical Information Technology, Inc. Office: 781-774-5156 | Mobile: 508-713-2499 lhaley(a)meditech.com MEDITECH Circle, Westwood, MA 02090 Main: 781-821-3000 | Fax: 781-821-2199 --=20 <https://ehr.meditech.com/expanse>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =20 <https://www.linkedin.com/company/meditech>=C2=A0 =20 <https://twitter.com/MEDITECH>=C2=A0=C2=A0 <https://www.facebook.com/Medite= chEHR> Subscribe=20 <https://info.meditech.com/get-great-meditech-content?hsCtaTracking=3D86429= 9ec-5abf-4004-9c6d-2d051794101f%7Cc911be42-538a-4a48-8dca-a6d4001c6326>=20 to receive emails from MEDITECH or to change email preferences. --00000000000062d6a8059f1bda34 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">FOUND THE ISSUE!=C2=A0 So - in GDB , while paused in the &= quot;{mM}" processing that ber_scanf does (called from=C2=A0ldap_get_a= ttribute_ber), I kept seeing the variable arguments list not properly setti= ng off --- and sure enough, digging in memory, on the stack was 0x100000000= ...=C2=A0 which was the cause of the eventual segfault.<div><br></div><div= >Well, backtracking to the ber_scanf call itself, I see a zero 0 which isn&= #39;t cast to the ber_len_t type, and as such, will only occupy 4 bytes as = a sizeof=C2=A0int - instead of (( on my system 8, for sizeof (ber_len_t).= =C2=A0 So - the solution was just=C2=A0to cast the argument.=C2=A0 So that = the=C2=A0cookie.off =3D va_arg( ap, ber_len_t ); will unpack only bytes we&= #39;ve intentionally sent it -- not garbage left over.</div><div><br></div>= <div>So - the change suggested is:</div><div><br></div><div><br></div><div>= <font face=3D"monospace">diff --git a/libraries/libldap/getattr.c b/librari= es/libldap/getattr.c<br>index 31784d765..0300ea574 100644<br>--- a/librarie= s/libldap/getattr.c<br>+++ b/libraries/libldap/getattr.c<br>@@ -147,7 +147,= 7 @@ ldap_get_attribute_ber( LDAP *ld, LDAPMessage *entry, BerElement *ber,= <br><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /* skip seq= uence, snarf attribute type */<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 tag =3D ber_scanf( ber, vals ? "{mM}" : "{mx}= ", attr, vals,<br>- =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 &siz, 0 );<br>+ =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 &siz, (ber_len_t)0 );= <br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if( tag =3D=3D = LBER_ERROR ) {<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 rc =3D ld->ld_errno =3D LDAP_DECODING_ERROR;= <br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }</font><br></d= iv><div><br></div><div><br></div><div>I hope you can take this haphazard is= sue submit, and do whatever is right with it - to get this patch considered= .=C2=A0 Thanks!</div><div><br></div><div><br></div></div><br><div class=3D"= gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, Feb 21, 2020 at = 1:06 PM Lexi Haley <<a href=3D"mailto:lhaley@meditech.com">lhaley@medite= ch.com</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"m= argin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left= :1ex"><div dir=3D"ltr">continuing notes - as I am quite accustomed to worki= ng with the data structures and processes for LDAP - my hacky fudge was jus= t that - and also useless.=C2=A0 By bailing out at that point, ldapsearch d= oesn't list the tag=3Dvalue results.=C2=A0 I am continuing to dig aroun= d ...<div><br></div><div>Lexi</div></div><br><div class=3D"gmail_quote"><di= v dir=3D"ltr" class=3D"gmail_attr">On Thu, Feb 20, 2020 at 3:09 PM <<a h= ref=3D"mailto:openldap-its@openldap.org" target=3D"_blank">openldap-its@ope= nldap.org</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style= =3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding= -left:1ex"><br> *** THIS IS AN AUTOMATICALLY GENERATED REPLY ***<br> <br> Thanks for your report to the OpenLDAP Issue Tracking System.=C2=A0 Your<br= > report has been assigned the tracking number ITS#9175.<br> <br> One of our support engineers will look at your report in due course.<br> Note that this may take some time because our support engineers<br> are volunteers.=C2=A0 They only work on OpenLDAP when they have spare<br> time.<br> <br> If you need to provide additional information in regards to your<br> issue report, you may do so by replying to this message.=C2=A0 Note that<br= > any mail sent to <a href=3D"mailto:openldap-its@openldap.org" target=3D"_bl= ank">openldap-its(a)openldap.org</a> with (ITS#9175)<br> in the subject will automatically be attached to the issue report.<br> <br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 mailto:<a href=3D"mailto:openldap-its@openldap.= org" target=3D"_blank">openldap-its(a)openldap.org</a>?subject=3D(ITS#9175)<b= r> <br> You may follow the progress of this report by loading the following<br> URL in a web browser:<br> =C2=A0 =C2=A0 <a href=3D"http://www.OpenLDAP.org/its/index.cgi?findid=3D917= 5" rel=3D"noreferrer" target=3D"_blank">http://www.OpenLDAP.org/its/index.c= gi?findid=3D9175</a><br> <br> Please remember to retain your issue tracking number (ITS#9175)<br> on any further messages you send to us regarding this report.=C2=A0 If<br> you don't then you'll just waste our time and yours because we<br> won't be able to properly track the report.<br> <br> Please note that the Issue Tracking System is not intended to<br> be used to seek help in the proper use of OpenLDAP Software.<br> Such requests will be closed.<br> <br> OpenLDAP Software is user supported.<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 <a href=3D"http://www.OpenLDAP.org/support/" re= l=3D"noreferrer" target=3D"_blank">http://www.OpenLDAP.org/support/</a><br> <br> --------------<br> Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved.<br> <br> </blockquote></div><br clear=3D"all"><div><br></div>-- <br><div dir=3D"ltr"= ><div dir=3D"ltr"><div><div dir=3D"ltr"><div><div dir=3D"ltr"><p dir=3D"ltr= " style=3D"color:rgb(80,0,80);line-height:1.38;margin-top:0pt;margin-bottom= :0pt"><span style=3D"font-size:13pt;font-family:Verdana;color:rgb(0,0,0);fo= nt-weight:700;vertical-align:baseline;white-space:pre-wrap">Lexi Haley </sp= an><span style=3D"color:rgb(102,102,102);font-family:Verdana;font-size:13.3= 333px;white-space:pre-wrap">(she/her/hers)</span></p><p dir=3D"ltr" style= =3D"color:rgb(80,0,80);line-height:1.38;margin-top:0pt;margin-bottom:0pt"><= span style=3D"font-size:10pt;font-family:Verdana;color:rgb(102,102,102);ver= tical-align:baseline;white-space:pre-wrap">Computer Scientist, System Tools= , Advanced Technology Division</span></p><p dir=3D"ltr" style=3D"color:rgb(= 80,0,80);line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style=3D"= font-size:10pt;font-family:Verdana;color:rgb(102,102,102);vertical-align:ba= seline;white-space:pre-wrap">Medical Information Technology, Inc.</span></p= ><p dir=3D"ltr" style=3D"color:rgb(80,0,80);line-height:1.38;margin-top:0pt= ;margin-bottom:0pt"><span style=3D"font-size:10pt;font-family:Verdana;color= :rgb(102,102,102);vertical-align:baseline;white-space:pre-wrap">Office: 781= -774-5156 | Mobile: 508-713-2499</span></p><p style=3D"color:rgb(80,0,80);l= ine-height:1.38;margin-top:0pt;margin-bottom:0pt"><font face=3D"Verdana"><s= pan style=3D"font-size:13.3333px;white-space:pre-wrap"><a href=3D"mailto:lh= aley(a)meditech.com" target=3D"_blank">lhaley(a)meditech.com</a></span></font><= /p><p dir=3D"ltr" style=3D"color:rgb(80,0,80);line-height:1.38;margin-top:0= pt;margin-bottom:0pt"><span style=3D"font-size:10pt;font-family:Verdana;col= or:rgb(102,102,102);vertical-align:baseline;white-space:pre-wrap">MEDITECH = Circle, Westwood, MA 02090</span></p><p dir=3D"ltr" style=3D"color:rgb(80,0= ,80);line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style=3D"font= -size:10pt;font-family:Verdana;color:rgb(102,102,102);vertical-align:baseli= ne;white-space:pre-wrap">Main: 781-821-3000 | Fax: 781-821-2199</span></p><= /div></div></div></div></div></div> </blockquote></div><br clear=3D"all"><div><br></div>-- <br><div dir=3D"ltr"= class=3D"gmail_signature"><div dir=3D"ltr"><div><div dir=3D"ltr"><div><div= dir=3D"ltr"><p dir=3D"ltr" style=3D"color:rgb(80,0,80);line-height:1.38;ma= rgin-top:0pt;margin-bottom:0pt"><span style=3D"font-size:13pt;font-family:V= erdana;color:rgb(0,0,0);font-weight:700;vertical-align:baseline;white-space= :pre-wrap">Lexi Haley </span><span style=3D"color:rgb(102,102,102);font-fam= ily:Verdana;font-size:13.3333px;white-space:pre-wrap">(she/her/hers)</span>= </p><p dir=3D"ltr" style=3D"color:rgb(80,0,80);line-height:1.38;margin-top:= 0pt;margin-bottom:0pt"><span style=3D"font-size:10pt;font-family:Verdana;co= lor:rgb(102,102,102);vertical-align:baseline;white-space:pre-wrap">Computer= Scientist, System Tools, Advanced Technology Division</span></p><p dir=3D"= ltr" style=3D"color:rgb(80,0,80);line-height:1.38;margin-top:0pt;margin-bot= tom:0pt"><span style=3D"font-size:10pt;font-family:Verdana;color:rgb(102,10= 2,102);vertical-align:baseline;white-space:pre-wrap">Medical Information Te= chnology, Inc.</span></p><p dir=3D"ltr" style=3D"color:rgb(80,0,80);line-he= ight:1.38;margin-top:0pt;margin-bottom:0pt"><span style=3D"font-size:10pt;f= ont-family:Verdana;color:rgb(102,102,102);vertical-align:baseline;white-spa= ce:pre-wrap">Office: 781-774-5156 | Mobile: 508-713-2499</span></p><p style= =3D"color:rgb(80,0,80);line-height:1.38;margin-top:0pt;margin-bottom:0pt"><= font face=3D"Verdana"><span style=3D"font-size:13.3333px;white-space:pre-wr= ap"><a href=3D"mailto:lhaley@meditech.com" target=3D"_blank">lhaley@meditec= h.com</a></span></font></p><p dir=3D"ltr" style=3D"color:rgb(80,0,80);line-= height:1.38;margin-top:0pt;margin-bottom:0pt"><span style=3D"font-size:10pt= ;font-family:Verdana;color:rgb(102,102,102);vertical-align:baseline;white-s= pace:pre-wrap">MEDITECH Circle, Westwood, MA 02090</span></p><p dir=3D"ltr"= style=3D"color:rgb(80,0,80);line-height:1.38;margin-top:0pt;margin-bottom:= 0pt"><span style=3D"font-size:10pt;font-family:Verdana;color:rgb(102,102,10= 2);vertical-align:baseline;white-space:pre-wrap">Main: 781-821-3000 | Fax: = 781-821-2199</span></p></div></div></div></div></div></div> <br> <a href=3D"https://ehr.meditech.com/expanse" target=3D"_blank"><img src=3D"= https://home.meditech.com/en/d/home/images/meditechemailsignaturelogo2018ex= panse.jpg"></a><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <a href=3D"ht= tps://www.linkedin.com/company/meditech" target=3D"_blank"><img src=3D"http= s://home.meditech.com/en/d/home/images/emailsignaturelinkedin20pixels.gif" = style=3D"font-size:1.3em"></a><span style=3D"font-size:1.3em">=C2=A0 </span= ><a href=3D"https://twitter.com/MEDITECH" target=3D"_blank"><img src=3D"htt= ps://home.meditech.com/en/d/home/images/emailsignaturetwitter20pixels.gif" = style=3D"font-size:1.3em"></a><span style=3D"font-size:1.3em">=C2=A0=C2=A0<= /span><a href=3D"https://www.facebook.com/MeditechEHR" target=3D"_blank"><i= mg src=3D"https://home.meditech.com/en/d/home/images/emailsignaturefacebook= 20pixels.gif" style=3D"font-size:1.3em"></a></div><div><div><a href=3D"http= s://info.meditech.com/get-great-meditech-content?hsCtaTracking=3D864299ec-5= abf-4004-9c6d-2d051794101f%7Cc911be42-538a-4a48-8dca-a6d4001c6326" target= =3D"_blank"><span style=3D"font-size:10pt;font-family:Verdana;color:rgb(17,= 85,204);vertical-align:baseline;white-space:pre-wrap">Subscribe</span></a><= span style=3D"font-size:10pt;font-family:Verdana;vertical-align:baseline;wh= ite-space:pre-wrap"> </span><span style=3D"font-size:10pt;font-family:Verda= na;color:rgb(102,102,102);vertical-align:baseline;white-space:pre-wrap">to = receive emails from MEDITECH or to change email preferences.</span></div></= div> --00000000000062d6a8059f1bda34--

1 0

Re: (ITS#9175) ldapsearch segfault
by lhaley＠meditech.com 21 Feb '20

21 Feb '20

--000000000000ecfe33059f19e40d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable continuing notes - as I am quite accustomed to working with the data structures and processes for LDAP - my hacky fudge was just that - and also useless. By bailing out at that point, ldapsearch doesn't list the tag=3Dvalue results. I am continuing to dig around ... Lexi On Thu, Feb 20, 2020 at 3:09 PM <openldap-its(a)openldap.org> wrote: > > *** THIS IS AN AUTOMATICALLY GENERATED REPLY *** > > Thanks for your report to the OpenLDAP Issue Tracking System. Your > report has been assigned the tracking number ITS#9175. > > One of our support engineers will look at your report in due course. > Note that this may take some time because our support engineers > are volunteers. They only work on OpenLDAP when they have spare > time. > > If you need to provide additional information in regards to your > issue report, you may do so by replying to this message. Note that > any mail sent to openldap-its(a)openldap.org with (ITS#9175) > in the subject will automatically be attached to the issue report. > > mailto:openldap-its@openldap.org?subject=3D(ITS#9175) > > You may follow the progress of this report by loading the following > URL in a web browser: > http://www.OpenLDAP.org/its/index.cgi?findid=3D9175 > > Please remember to retain your issue tracking number (ITS#9175) > on any further messages you send to us regarding this report. If > you don't then you'll just waste our time and yours because we > won't be able to properly track the report. > > Please note that the Issue Tracking System is not intended to > be used to seek help in the proper use of OpenLDAP Software. > Such requests will be closed. > > OpenLDAP Software is user supported. > http://www.OpenLDAP.org/support/ > > -------------- > Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved. > > --=20 Lexi Haley (she/her/hers) Computer Scientist, System Tools, Advanced Technology Division Medical Information Technology, Inc. Office: 781-774-5156 | Mobile: 508-713-2499 lhaley(a)meditech.com MEDITECH Circle, Westwood, MA 02090 Main: 781-821-3000 | Fax: 781-821-2199 --=20 <https://ehr.meditech.com/expanse>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =20 <https://www.linkedin.com/company/meditech>=C2=A0 =20 <https://twitter.com/MEDITECH>=C2=A0=C2=A0 <https://www.facebook.com/Medite= chEHR> Subscribe=20 <https://info.meditech.com/get-great-meditech-content?hsCtaTracking=3D86429= 9ec-5abf-4004-9c6d-2d051794101f%7Cc911be42-538a-4a48-8dca-a6d4001c6326>=20 to receive emails from MEDITECH or to change email preferences. --000000000000ecfe33059f19e40d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">continuing notes - as I am quite accustomed to working wit= h the data structures and processes for LDAP - my hacky fudge was just that= - and also useless.=C2=A0 By bailing out at that point, ldapsearch doesn&#= 39;t list the tag=3Dvalue results.=C2=A0 I am continuing to dig around ...<= div><br></div><div>Lexi</div></div><br><div class=3D"gmail_quote"><div dir= =3D"ltr" class=3D"gmail_attr">On Thu, Feb 20, 2020 at 3:09 PM <<a href= =3D"mailto:openldap-its@openldap.org">openldap-its(a)openldap.org</a>> wro= te:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px = 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br> *** THIS IS AN AUTOMATICALLY GENERATED REPLY ***<br> <br> Thanks for your report to the OpenLDAP Issue Tracking System.=C2=A0 Your<br= > report has been assigned the tracking number ITS#9175.<br> <br> One of our support engineers will look at your report in due course.<br> Note that this may take some time because our support engineers<br> are volunteers.=C2=A0 They only work on OpenLDAP when they have spare<br> time.<br> <br> If you need to provide additional information in regards to your<br> issue report, you may do so by replying to this message.=C2=A0 Note that<br= > any mail sent to <a href=3D"mailto:openldap-its@openldap.org" target=3D"_bl= ank">openldap-its(a)openldap.org</a> with (ITS#9175)<br> in the subject will automatically be attached to the issue report.<br> <br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 mailto:<a href=3D"mailto:openldap-its@openldap.= org" target=3D"_blank">openldap-its(a)openldap.org</a>?subject=3D(ITS#9175)<b= r> <br> You may follow the progress of this report by loading the following<br> URL in a web browser:<br> =C2=A0 =C2=A0 <a href=3D"http://www.OpenLDAP.org/its/index.cgi?findid=3D917= 5" rel=3D"noreferrer" target=3D"_blank">http://www.OpenLDAP.org/its/index.c= gi?findid=3D9175</a><br> <br> Please remember to retain your issue tracking number (ITS#9175)<br> on any further messages you send to us regarding this report.=C2=A0 If<br> you don't then you'll just waste our time and yours because we<br> won't be able to properly track the report.<br> <br> Please note that the Issue Tracking System is not intended to<br> be used to seek help in the proper use of OpenLDAP Software.<br> Such requests will be closed.<br> <br> OpenLDAP Software is user supported.<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 <a href=3D"http://www.OpenLDAP.org/support/" re= l=3D"noreferrer" target=3D"_blank">http://www.OpenLDAP.org/support/</a><br> <br> --------------<br> Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved.<br> <br> </blockquote></div><br clear=3D"all"><div><br></div>-- <br><div dir=3D"ltr"= class=3D"gmail_signature"><div dir=3D"ltr"><div><div dir=3D"ltr"><div><div= dir=3D"ltr"><p dir=3D"ltr" style=3D"color:rgb(80,0,80);line-height:1.38;ma= rgin-top:0pt;margin-bottom:0pt"><span style=3D"font-size:13pt;font-family:V= erdana;color:rgb(0,0,0);font-weight:700;vertical-align:baseline;white-space= :pre-wrap">Lexi Haley </span><span style=3D"color:rgb(102,102,102);font-fam= ily:Verdana;font-size:13.3333px;white-space:pre-wrap">(she/her/hers)</span>= </p><p dir=3D"ltr" style=3D"color:rgb(80,0,80);line-height:1.38;margin-top:= 0pt;margin-bottom:0pt"><span style=3D"font-size:10pt;font-family:Verdana;co= lor:rgb(102,102,102);vertical-align:baseline;white-space:pre-wrap">Computer= Scientist, System Tools, Advanced Technology Division</span></p><p dir=3D"= ltr" style=3D"color:rgb(80,0,80);line-height:1.38;margin-top:0pt;margin-bot= tom:0pt"><span style=3D"font-size:10pt;font-family:Verdana;color:rgb(102,10= 2,102);vertical-align:baseline;white-space:pre-wrap">Medical Information Te= chnology, Inc.</span></p><p dir=3D"ltr" style=3D"color:rgb(80,0,80);line-he= ight:1.38;margin-top:0pt;margin-bottom:0pt"><span style=3D"font-size:10pt;f= ont-family:Verdana;color:rgb(102,102,102);vertical-align:baseline;white-spa= ce:pre-wrap">Office: 781-774-5156 | Mobile: 508-713-2499</span></p><p style= =3D"color:rgb(80,0,80);line-height:1.38;margin-top:0pt;margin-bottom:0pt"><= font face=3D"Verdana"><span style=3D"font-size:13.3333px;white-space:pre-wr= ap"><a href=3D"mailto:lhaley@meditech.com" target=3D"_blank">lhaley@meditec= h.com</a></span></font></p><p dir=3D"ltr" style=3D"color:rgb(80,0,80);line-= height:1.38;margin-top:0pt;margin-bottom:0pt"><span style=3D"font-size:10pt= ;font-family:Verdana;color:rgb(102,102,102);vertical-align:baseline;white-s= pace:pre-wrap">MEDITECH Circle, Westwood, MA 02090</span></p><p dir=3D"ltr"= style=3D"color:rgb(80,0,80);line-height:1.38;margin-top:0pt;margin-bottom:= 0pt"><span style=3D"font-size:10pt;font-family:Verdana;color:rgb(102,102,10= 2);vertical-align:baseline;white-space:pre-wrap">Main: 781-821-3000 | Fax: = 781-821-2199</span></p></div></div></div></div></div></div> <br> <a href=3D"https://ehr.meditech.com/expanse" target=3D"_blank"><img src=3D"= https://home.meditech.com/en/d/home/images/meditechemailsignaturelogo2018ex= panse.jpg"></a><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <a href=3D"ht= tps://www.linkedin.com/company/meditech" target=3D"_blank"><img src=3D"http= s://home.meditech.com/en/d/home/images/emailsignaturelinkedin20pixels.gif" = style=3D"font-size:1.3em"></a><span style=3D"font-size:1.3em">=C2=A0 </span= ><a href=3D"https://twitter.com/MEDITECH" target=3D"_blank"><img src=3D"htt= ps://home.meditech.com/en/d/home/images/emailsignaturetwitter20pixels.gif" = style=3D"font-size:1.3em"></a><span style=3D"font-size:1.3em">=C2=A0=C2=A0<= /span><a href=3D"https://www.facebook.com/MeditechEHR" target=3D"_blank"><i= mg src=3D"https://home.meditech.com/en/d/home/images/emailsignaturefacebook= 20pixels.gif" style=3D"font-size:1.3em"></a></div><div><div><a href=3D"http= s://info.meditech.com/get-great-meditech-content?hsCtaTracking=3D864299ec-5= abf-4004-9c6d-2d051794101f%7Cc911be42-538a-4a48-8dca-a6d4001c6326" target= =3D"_blank"><span style=3D"font-size:10pt;font-family:Verdana;color:rgb(17,= 85,204);vertical-align:baseline;white-space:pre-wrap">Subscribe</span></a><= span style=3D"font-size:10pt;font-family:Verdana;vertical-align:baseline;wh= ite-space:pre-wrap"> </span><span style=3D"font-size:10pt;font-family:Verda= na;color:rgb(102,102,102);vertical-align:baseline;white-space:pre-wrap">to = receive emails from MEDITECH or to change email preferences.</span></div></= div> --000000000000ecfe33059f19e40d--

1 0

Re: (ITS#9171) slapd with ppolicy and pwdAccountLockedTime crashes
by ondra＠mistotebe.net 21 Feb '20

21 Feb '20

On Mon, Feb 17, 2020 at 02:17:32PM +0000, tokos(a)ipp.cas.cz wrote: > Hi Ondrej, > > I uploaded my configuration here(ftp.openldap.org/incoming) : Hi Stanislav, thanks for the information, I have been able to reproduce the issue and pushed a fix to master (commit 140b676bc1bd786f9fd1e7b047981e84b57cb354). Regards, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

RE: Re: (ITS#9017) Improving performance of commit sync in Windows
by kriszyp＠gmail.com 21 Feb '20

21 Feb '20

<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" xmlns:w=3D"urn:sc= hemas-microsoft-com:office:word" xmlns:m=3D"http://schemas.microsoft.com/of= fice/2004/12/omml" xmlns=3D"http://www.w3.org/TR/REC-html40"><head><meta ht= tp-equiv=3DContent-Type content=3D"text/html; charset=3Dutf-8"><meta name= =3DGenerator content=3D"Microsoft Word 15 (filtered medium)"><style></style></head><body lang=3DEN-CA link=3Dblue vlink=3D"#954F72"><div cla= ss=3DWordSection1><p class=3DMsoNormal>Sorry, I should have added a little = more detail. Specifically, I was seeing the `pos` variable in `mdb_page_flu= sh` going over 2^31, and this being manifested in failed shift right here (= resulting in 2^32 -1):<o:p></o:p></p><p class=3DMsoNormal><a href=3D"https:= //github.com/LMDB/lmdb/blob/mdb.master/libraries/liblmdb/mdb.c#L3711">https= ://github.com/LMDB/lmdb/blob/mdb.master/libraries/liblmdb/mdb.c#L3711</a> <= /p><p class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal>Thanks,<b= r>Kris</p><p class=3DMsoNormal><o:p> </o:p></p><div style=3D'mso-eleme= nt:para-border-div;border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt= 0cm 0cm 0cm'><p class=3DMsoNormal style=3D'border:none;padding:0cm'><b>Fro= m: </b><a href=3D"mailto:hyc@symas.com">Howard Chu</a><br><b>Sent: </b>Febr= uary 20, 2020 9:08 PM<br><b>To: </b><a href=3D"mailto:kriszyp@gmail.com">kr= iszyp(a)gmail.com</a><br><b>Cc: </b><a href=3D"mailto:openldap-its@openldap.o= rg">openldap-its(a)OpenLDAP.org</a><br><b>Subject: </b>Re: (ITS#9017) Improvi= ng performance of commit sync in Windows</p></div><p class=3DMsoNormal><o:p= > </o:p></p><p class=3DMsoNormal>Howard Chu wrote:</p><p class=3DMsoNo= rmal>> There should be an off64_t type instead.</p><p class=3DMsoNormal>= <o:p> </o:p></p><p class=3DMsoNormal><o:p> </o:p></p><p class=3DM= soNormal>> But it looks to me like only the env->me_size field could = ever overflow,</p><p class=3DMsoNormal>> and using size_t for that shoul= d be fine. The other uses are for the meta page, which is always either off= set 0 or</p><p class=3DMsoNormal>> offset 4096 (with 4KB pagesize), and = the lockfile, which is always smaller than 2GB.</p><p class=3DMsoNormal><o:= p> </o:p></p><p class=3DMsoNormal>Ignore that, I was looking at the 0.= 9 branch when I wrote that.</p><p class=3DMsoNormal><o:p> </o:p></p><p= class=3DMsoNormal>-- </p><p class=3DMsoNormal>=C2=A0=C2=A0-- Howard Chu</p= ><p class=3DMsoNormal>=C2=A0 CTO, Symas Corp.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 http://www.symas.com</p><p class=3DMsoNormal= >=C2=A0 Director, Highland Sun=C2=A0=C2=A0=C2=A0=C2=A0 http://highlandsun.c= om/hyc/</p><p class=3DMsoNormal>=C2=A0 Chief Architect, OpenLDAP=C2=A0 http= ://www.openldap.org/project/</p><p class=3DMsoNormal><o:p> </o:p></p><= /div></body></html>=

1 0

Re: (ITS#9017) Improving performance of commit sync in Windows
by hyc＠symas.com 21 Feb '20

21 Feb '20

Howard Chu wrote: > There should be an off64_t type instead. > But it looks to me like only the env->me_size field could ever overflow, > and using size_t for that should be fine. The other uses are for the meta page, which is always either offset 0 or > offset 4096 (with 4KB pagesize), and the lockfile, which is always smaller than 2GB. Ignore that, I was looking at the 0.9 branch when I wrote that. -- -- 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#9017) Improving performance of commit sync in Windows
by hyc＠symas.com 21 Feb '20

21 Feb '20

kriszyp(a)gmail.com wrote: > However, in trying to test the mdb.master branch code with our application/server (we were previously using the 0.9 branch), there was a regression causing it > to crash pretty much any time we attempted to write to a db that was larger than 2GB. After some considerable testing and investigation (which is why it took a > while to get this finished), it seems the cause is the use of the off_t type for file pointer/positions, which appears to be a 32-bit signed integer compiling > on Windows. This overflows for dbs over 2GB and causes references that crash the process. Replacing all the off_t types with size_t (unsigned 64-bit), fixed > this issue. I am not sure if this is the right replacement type. I think this could also be addressed with compiler option for changing the file offset type > size, but that seems like a hazardous hoop to jump through. But the third commit, replacing the off_t with size_t definitely fixed the problem in our application. There should be an off64_t type instead. But it looks to me like only the env->me_size field could ever overflow, and using size_t for that should be fine. The other uses are for the meta page, which is always either offset 0 or offset 4096 (with 4KB pagesize), and the lockfile, which is always smaller than 2GB. > > https://github.com/LMDB/lmdb/commit/45cf4b6ede38565cfab1c40d0d77961a0cb22b9… -- -- 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: RE: Re: (ITS#9017) Improving performance of commit sync in Windows
by kriszyp＠gmail.com 21 Feb '20

21 Feb '20

<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" xmlns:w=3D"urn:sc= hemas-microsoft-com:office:word" xmlns:m=3D"http://schemas.microsoft.com/of= fice/2004/12/omml" xmlns=3D"http://www.w3.org/TR/REC-html40"><head><meta ht= tp-equiv=3DContent-Type content=3D"text/html; charset=3Dutf-8"><meta name= =3DGenerator content=3D"Microsoft Word 15 (filtered medium)"><style></style></head><body lang=3DEN-CA link=3Dblue vlink=3D"#954F72"><div cla= ss=3DWordSection1><p class=3DMsoNormal>Here is a pull request for these win= dows upgrades (I know it won=E2=80=99t be applied directly in GitHub, but s= eems a convenient host for the patches):</p><p class=3DMsoNormal><a href=3D= "https://github.com/LMDB/lmdb/pull/18"><span style=3D'color:#954F72'>https:= //github.com/LMDB/lmdb/pull/18</span></a><o:p></o:p></p><p class=3DMsoNorma= l><o:p> </o:p></p><p class=3DMsoNormal>The first commit is basically t= he changes mentioned in this thread for improving sync performance by using= write-through writes instead FlushFileBuffers/FlushViewOfFile, reapplied t= o the mdb.master branch, with conflicts resolved.</p><p class=3DMsoNormal><= a href=3D"https://github.com/LMDB/lmdb/commit/204d1710d7a34eff142f2654d7678= 182e1b9e054.patch"><span style=3D'color:#954F72'>https://github.com/LMDB/lm= db/commit/204d1710d7a34eff142f2654d7678182e1b9e054.patch</span></a></p><p c= lass=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal>The second commi= t adds support for an option for opening map files by providing the mapsize= as the file size (MaximumSize) to NtCreateSection (which also improves per= formance and prevents freezing caused by file growth). I implemented this a= s a compiler preprocessor define, as requested. However, I would note that = I would still prefer this to be a runtime option. When bundling LMDB in a n= ode package, there is no way to parameterize the compiler options (that I k= now of) for distribution, and it would be nice to have this an option for d= ifferent users of the node package.</p><p class=3DMsoNormal><a href=3D"http= s://github.com/LMDB/lmdb/commit/6f94bb1da1812c1ddb68e33448c9cd381674b02d.pa= tch"><span style=3D'color:#954F72'>https://github.com/LMDB/lmdb/commit/6f94= bb1da1812c1ddb68e33448c9cd381674b02d.patch</span></a></p><p class=3DMsoNorm= al><o:p> </o:p></p><p class=3DMsoNormal>However, in trying to test the= mdb.master branch code with our application/server (we were previously usi= ng the 0.9 branch), there was a regression causing it to crash pretty much = any time we attempted to write to a db that was larger than 2GB. After some= considerable testing and investigation (which is why it took a while to ge= t this finished), it seems the cause is the use of the off_t type for file = pointer/positions, which appears to be a 32-bit signed integer compiling on= Windows. This overflows for dbs over 2GB and causes references that crash = the process. Replacing all the off_t types with size_t (unsigned 64-bit), f= ixed this issue. I am not sure if this is the right replacement type. I thi= nk this could also be addressed with compiler option for changing the file = offset type size, but that seems like a hazardous hoop to jump through. But= the third commit, replacing the off_t with size_t definitely fixed the pro= blem in our application.</p><p class=3DMsoNormal><a href=3D"https://github.= com/LMDB/lmdb/commit/45cf4b6ede38565cfab1c40d0d77961a0cb22b9e.patch"><span = style=3D'color:#954F72'>https://github.com/LMDB/lmdb/commit/45cf4b6ede38565= cfab1c40d0d77961a0cb22b9e.patch</span></a></p><p class=3DMsoNormal><o:p>&nb= sp;</o:p></p><p class=3DMsoNormal>With these three commits we are seeing so= lid stability and performance on Windows with the master branch. Thanks for= considering this!</p><p class=3DMsoNormal><o:p> </o:p></p><p class=3D= MsoNormal>Thanks,<br>Kris</p><p class=3DMsoNormal><o:p> </o:p></p><div= style=3D'mso-element:para-border-div;border:none;border-top:solid #E1E1E1 = 1.0pt;padding:3.0pt 0cm 0cm 0cm'><p class=3DMsoNormal style=3D'border:none;= padding:0cm'><b>From: </b><a href=3D"mailto:kriszyp@gmail.com">kriszyp@gmai= l.com</a><br><b>Sent: </b>February 18, 2020 1:06 PM<br><b>To: </b><a href= =3D"mailto:hyc@symas.com">Howard Chu</a><br><b>Cc: </b><a href=3D"mailto:op= enldap-its(a)openldap.org">openldap-its(a)OpenLDAP.org</a><br><b>Subject: </b>R= E: Re: (ITS#9017) Improving performance of commit sync in Windows</p></div>= <p class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal>Looking into= the APIs, I would guess that CreateFileMapping=E2=80=99s dwMaximumSizeHigh= and dwMaximumSizeLow arguments are mapped to NtCreateSection=E2=80=99s Max= imumSize argument (4<sup>th</sup> argument). In LMDB=E2=80=99s 0.9 CreateFi= leMapping call, the size is provided (since it is required), whereas NtCrea= teSection has MaximumSize as optional, and in LMDB (mdb.master), it is not = provided. Passing the size in (with MaximumSize argument) to NtCreateSectio= n seems to result in the same behavior as CreateFileMapping of preallocatin= g a file size equivalent to the max/mapping size, rather than dynamically g= rowing.<o:p></o:p></p><p class=3DMsoNormal><o:p> </o:p></p><p class=3D= MsoNormal>It is challenging to readily test for the performance issues; it = took a fair bit of effort and load testing to trigger the long-duration per= formance/freezing issues we had seen before on Azure. However, in some more= isolated tests, providing a MaximumSize to NtCreateSection does seem to pe= rform better than leaving it unspecified (specifically the system CPU usage= seems to about be about twice as much with dynamic growth than fixed file = size), and the performance seems about the same as CreateFileMapping. And I= think we both had suspected that it was likely due to the overhead or inef= ficiencies in how Windows was dynamically growing the (size of the) mapped = file, and having Windows used a predefined fixed file size, whether through= NtCreateSection or CreateFileMapping, probably would prevent these slowdow= n issues.<o:p></o:p></p><p class=3DMsoNormal><o:p> </o:p></p><p class= =3DMsoNormal>But, whether we use NtCreateSection or CreateFileMapping, we a= re still faced with the same trade-off of whether to use dynamic Windows-co= ntrolled file growth (convenient since the map size can be set arbitrarily = large), or using pre-specified file size (to avoid the slowing/freezing tha= t seems to sometimes result from dynamic Windows growth). So I assume it wo= uld still be reasonable to offer a compile time option, so users could opt-= in to using a fixed file size (provide the MaximumSize to NtCreateSection)?= Fortunately this would be a trivial addition, just a few lines of code to = use the preprocessor switch to supply this argument.<o:p></o:p></p><p class= =3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal><a href=3D"http://un= documented.ntinternals.net/index.html?page=3DUserMode%2FUndocumented%20Func= tions%2FNT%20Objects%2FSection%2FNtMapViewOfSection.html">http://undocument= ed.ntinternals.net/index.html?page=3DUserMode%2FUndocumented%20Functions%2F= NT%20Objects%2FSection%2FNtMapViewOfSection.html</a><o:p></o:p></p><p class= =3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal>Thanks,<br>Kris<o:p>= </o:p></p><p class=3DMsoNormal><o:p> </o:p></p><div style=3D'border:no= ne;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm'><p class=3DMso= Normal><b>From: </b><a href=3D"mailto:hyc@symas.com">Howard Chu</a><br><b>S= ent: </b>February 18, 2020 8:15 AM<br><b>To: </b><a href=3D"mailto:kriszyp@= gmail.com">Kris Zyp</a><br><b>Cc: </b><a href=3D"mailto:openldap-its@openld= ap.org">openldap-its(a)OpenLDAP.org</a><br><b>Subject: </b>Re: (ITS#9017) Imp= roving performance of commit sync in Windows<o:p></o:p></p></div><p class= =3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal>Kris Zyp wrote:<o:p>= </o:p></p><p class=3DMsoNormal>> Yes, I will work on upgrading this patc= h to 1.0.<o:p></o:p></p><p class=3DMsoNormal>> <o:p></o:p></p><p class= =3DMsoNormal>> However, I believe in order to realize optimal Windows pe= rformance without regression/slow-downs, I will also need to disable the us= e of NTDLL (and use direct<o:p></o:p></p><p class=3DMsoNormal>> CreateFi= leMapping memory maps instead), as mentioned  http://www.openldap.org/= lists/openldap-bugs/201902/msg00009.html. You had mentioned in that thread = that<o:p></o:p></p><p class=3DMsoNormal>> the NTDLL code wasn't destined= for release, is that still the case (it is still in the mdb.master branch)= ? If you are intending to release (1.0) with the<o:p></o:p></p><p class=3DM= soNormal>> NTDLL-based memory maps (which is understandable, can certain= ly be an easier path for Windows users getting started), I will also need t= o add the compiler<o:p></o:p></p><p class=3DMsoNormal>> option to disabl= e it. Anyway, I will work on creating a PR with both these patches.<o:p></o= :p></p><p class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal>Might= be interesting to investigate why the behavior with NTDLL is so much slowe= r on Azure. Since<o:p></o:p></p><p class=3DMsoNormal>the Win32 APIs are imp= lemented on top of the NT APIs, you would expect them to perform identicall= y.<o:p></o:p></p><p class=3DMsoNormal>Perhaps there's some additional flag = that the Win32 API is passing to NT that is needed on Azure.<o:p></o:p></p>= <p class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal>> <o:p></= o:p></p><p class=3DMsoNormal>> Thanks,<o:p></o:p></p><p class=3DMsoNorma= l>> Kris<o:p></o:p></p><p class=3DMsoNormal>> <o:p></o:p></p><p class= =3DMsoNormal>> On Mon, Feb 17, 2020 at 8:14 AM Howard Chu <hyc(a)symas.= com <mailto:hyc@symas.com>> wrote:<o:p></o:p></p><p class=3DMsoNor= mal>> <o:p></o:p></p><p class=3DMsoNormal>>     K= ris Zyp wrote:<o:p></o:p></p><p class=3DMsoNormal>>   &nb= sp; > Sorry to keep pestering, but just pinging about this patch again, = as I still think this fix could benefit windows users. And at this point, I= think I can<o:p></o:p></p><p class=3DMsoNormal>>   &nbsp= ; say we<o:p></o:p></p><p class=3DMsoNormal>>     &g= t; have tested it pretty well, running on our servers for almost a year :).= <o:p></o:p></p><p class=3DMsoNormal>> <o:p></o:p></p><p class=3DMsoNorma= l>>     Looks like this patch is against the 0.9 rel= ease branch. I hit a bunch of conflicts<o:p></o:p></p><p class=3DMsoNormal>= >     trying to apply it to mdb.master. We'll be sto= pping work on 0.9 soon, and getting<o:p></o:p></p><p class=3DMsoNormal>>=      LMDB 1.0 out the door finally, so can you please v= erify that your changes will work<o:p></o:p></p><p class=3DMsoNormal>>&n= bsp;    on mdb.master as well?<o:p></o:p></p><p class=3DMsoN= ormal>> <o:p></o:p></p><p class=3DMsoNormal>>    = > Thanks,<o:p></o:p></p><p class=3DMsoNormal>>   &nbs= p; > Kris<o:p></o:p></p><p class=3DMsoNormal>>   &nbsp= ; ><o:p></o:p></p><p class=3DMsoNormal>>     >= On Wed, Sep 18, 2019 at 12:56 PM Kris Zyp <kriszyp(a)gmail.com <mailto= :kriszyp@gmail.com> <mailto:kriszyp@gmail.com <mailto:kriszyp@gmai= l.com>>> wrote:<o:p></o:p></p><p class=3DMsoNormal>> &nbsp= ;   ><o:p></o:p></p><p class=3DMsoNormal>>  &nbsp= ;  >     Checking on this again, is this still a pos= sibility for merging into LMDB? This fix is still working great (improved p= erformance) on our systems.<o:p></o:p></p><p class=3DMsoNormal>> &n= bsp;   >     Thanks,<o:p></o:p></p><p class=3DM= soNormal>>     >     Kris<o:p></o:= p></p><p class=3DMsoNormal>>     ><o:p></o:p></p>= <p class=3DMsoNormal>>     >     O= n Mon, Jun 17, 2019 at 1:04 PM Kris Zyp <kriszyp(a)gmail.com <mailto:kr= iszyp(a)gmail.com> <mailto:kriszyp@gmail.com <mailto:kriszyp@gmail.c= om>>> wrote:<o:p></o:p></p><p class=3DMsoNormal>>  &n= bsp;  ><o:p></o:p></p><p class=3DMsoNormal>>   &n= bsp; >         Is this still being considered/r= eviewed? Let me know if there are any other changes you would like me to ma= ke. This patch has continued to yield<o:p></o:p></p><p class=3DMsoNormal>&g= t;     >         significan= t and reliable performance improvements for us, and seems like it would be = nice for this to be available for other Windows users.<o:p></o:p></p><p cla= ss=3DMsoNormal>>     ><o:p></o:p></p><p class=3DM= soNormal>>     >        &nbsp= ;On Fri, May 3, 2019 at 3:52 PM Kris Zyp <kriszyp(a)gmail.com <mailto:k= riszyp(a)gmail.com> <mailto:kriszyp@gmail.com <mailto:kriszyp@gmail.= com>>> wrote:<o:p></o:p></p><p class=3DMsoNormal>>  &= nbsp;  ><o:p></o:p></p><p class=3DMsoNormal>>   &= nbsp; >             For the sake of p= utting this in the email thread (other code discussion in GitHub), here is = the latest squashed commit of the proposed patch (with<o:p></o:p></p><p cla= ss=3DMsoNormal>>     >       =      the on-demand, retained overlapped array to reduce re-= malloc and opening event handles):<o:p></o:p></p><p class=3DMsoNormal>>&= nbsp;    >            &nbsp= ;https://github.com/kriszyp/node-lmdb/commit/726a9156662c703bf3d453aab75ee2= 22072b990f<o:p></o:p></p><p class=3DMsoNormal>>     = ><o:p></o:p></p><p class=3DMsoNormal>> <o:p></o:p></p><p class=3DMsoN= ormal>> <o:p></o:p></p><p class=3DMsoNormal>>    = -- <o:p></o:p></p><p class=3DMsoNormal>>      = -- Howard Chu<o:p></o:p></p><p class=3DMsoNormal>>   &nb= sp;   CTO, Symas Corp.           http://= www.symas.com<o:p></o:p></p><p class=3DMsoNormal>>   &nbs= p;   Director, Highland Sun     http://highlandsun.com/= hyc/<o:p></o:p></p><p class=3DMsoNormal>>      = Chief Architect, OpenLDAP  http://www.openldap.org/project/<o:p></o:p= ></p><p class=3DMsoNormal>> <o:p></o:p></p><p class=3DMsoNormal><o:p>&nb= sp;</o:p></p><p class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal= >-- <o:p></o:p></p><p class=3DMsoNormal>  -- Howard Chu<o:p></o:p= ></p><p class=3DMsoNormal>  CTO, Symas Corp.    &n= bsp;      http://www.symas.com<o:p></o:p></p><p cl= ass=3DMsoNormal>  Director, Highland Sun     http:= //highlandsun.com/hyc/<o:p></o:p></p><p class=3DMsoNormal>  Chief Arch= itect, OpenLDAP  http://www.openldap.org/project/<o:p></o:p></p><p cla= ss=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal><o:p> </o:p><= /p></div></body></html>=

1 0

(ITS#9176) libldap support for TLSv1.3 Encrypted SNI
by ryan＠openldap.org 21 Feb '20

21 Feb '20

Full_Name: Ryan Tandy Version: master OS: Debian URL: Submission from: (NULL) (70.66.128.207) Submitted by: ryan ldap.google.com requires clients to support SNI and sends back an intentionally invalid certificate if it is not used. Affects libldap with both OpenSSL and GnuTLS. (Might want a separate ITS for each fix.) With OpenSSL: $ ./clients/tools/ldapsearch -H ldaps://ldap.google.com -x -d1 ldap_url_parse_ext(ldaps://ldap.google.com) ldap_create ldap_url_parse_ext(ldaps://ldap.google.com:636/??base) ldap_sasl_bind ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP ldap.google.com:636 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying 216.239.32.58:636 ldap_pvt_connect: fd: 3 tm: -1 async: 0 attempting to connect: connect success TLS trace: SSL_connect:before SSL initialization TLS trace: SSL_connect:SSLv3/TLS write client hello TLS trace: SSL_connect:SSLv3/TLS write client hello TLS trace: SSL_connect:SSLv3/TLS read server hello TLS trace: SSL_connect:TLSv1.3 read encrypted extensions TLS trace: SSL_connect:SSLv3/TLS read server certificate request TLS certificate verification: depth: 0, err: 18, subject: /OU=No SNI provided; please fix your client./CN=invalid2.invalid, issuer: /OU=No SNI provided; please fix your client./CN=invalid2.invalid TLS certificate verification: Error, self signed certificate TLS trace: SSL3 alert write:fatal:unknown CA TLS trace: SSL_connect:error in error TLS: can't connect: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed (self signed certificate). ldap_err2string ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) With GnuTLS: $ ./clients/tools/ldapsearch -H ldaps://ldap.google.com -x -d1 ldap_url_parse_ext(ldaps://ldap.google.com) ldap_create ldap_url_parse_ext(ldaps://ldap.google.com:636/??base) ldap_sasl_bind ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP ldap.google.com:636 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying 216.239.32.58:636 ldap_pvt_connect: fd: 3 tm: -1 async: 0 attempting to connect: connect success TLS: peer cert untrusted or revoked (0x42) TLS: can't connect: (unknown error code). ldap_err2string ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) When the client does not support SNI, this server sends back a dummy certificate: OU = "No SNI provided; please fix your client.", CN = invalid2.invalid which obviously does not validate. The same behaviour can be seen with "openssl s_client -noservername" or "gnutls-cli --disable-sni". For GnuTLS, we have to call gnutls_server_name_set(3) to enable SNI. The documentation notes that it should only be called with a DNS name, not with an IP address. I guess there's a corresponding call for OpenSSL. With GnuTLS, users can work around it for the short term by disabling TLSv1.3 via priority string, i.e.: LDAPTLS_CIPHER_SUITE='NORMAL:!VERS-TLS1.3' ./clients/tools/ldapsearch -H ldaps://ldap.google.com -x Not sure if the same can be done with OpenSSL.

1 0

(ITS#9175) ldapsearch segfault
by lhaley＠meditech.com 20 Feb '20

20 Feb '20

Full_Name: Lexi Haley Version: 02/20/2020 trunk commit 299fb490a27e7b0e5a60464e33f5ea04d00f0f7c OS: CYGWIN on Windows URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (208.206.3.188) Using clients/tools/ldapsearch to interact with my company's active directory, and I receive a segfault, in libraries/liblbver/decode.c . the 'gist' of the command I executed was: ldapsearch.exe -h companyADserver -b cn=users,dc=company,dc=com -s sub '(cn=z*)' cn the gdb backtrace is (omitting all the (arg=val) items for brevity: #0 ber_get_stringbvl (...) at decode.c:445 #1 0x0000000100435781 in ber_scanf (...) at decode.c:820 #2 0x000000010041a605 in ldap_get_attribute_ber (...) at getattr.c:149 #3 0x0000000100401d93 in print_entry (...) at ldapsearch.c:1758 #5 0x000000010043bfd7 in main (...) at ldapsearch.c:1510 and digging around - here is what I see going on. in decode.c, during the ber_get_stringbvl function, the passed in b (aka cookie from caller), has the following values: {choice = BvOff, option = 0, siz = 1, off = 4294967296, result = 0x800055410} notice that off is 0x100000000 - a likely ridiculous (and thus a possible MAGIC) value. examining in ber_scanf, looking at the memory for the va_args - i.e. examining ap - I see (sure enough) 0x100000000... As a hacky temporary workaround - I added to my ber_get_stringbvl , before even pulling the tag: } res; + if (b->off == 0x100000000) + return LBER_DEFAULT; tag = ber_skip_tag( ber, &bv.bv_len ); I did try rewinding my source back to OPENLDAP_REL_ENG_2_4_40 (2014) and then to OPENLDAP_REL_ENG_2_4_30 (2012) - and both compilations still yielded the segfault error I described above. I'm afraid I do not know much about ldap or active directory - so I easily might be omitting something relevant, and/or completely missing the mark in different ways. Feel free to ask me for more information, and/or suggest what I might try out. Thanks, Lexi

1 0

Re: (ITS#8639) Remove support for LANMAN
by fumiyas＠osstech.co.jp 20 Feb '20

20 Feb '20

Hi, I've created a path for smbk5pwd to disable the insecure sambaLMPassword support by default. https://github.com/osstech-jp/openldap/commit/bba50bf6533d8f67dcbfc990b6b31… https://github.com/osstech-jp/openldap/commit/bba50bf6533d8f67dcbfc990b6b31… -- -- Name: SATOH Fumiyasu @ OSS Technology Corp. (fumiyas @ osstech co jp) -- Business Home: https://www.OSSTech.co.jp/ -- GitHub Home: https://GitHub.com/fumiyas/ -- PGP Fingerprint: BBE1 A1C9 525A 292E 6729 CDEC ADC2 9DCA 5E1C CBCA

1 0