openldap-bugs

openldap-bugs@openldap.org

1 participants
21065 discussions

[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 10 Mar '20

10 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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs