- openldap-bugs - openldap.org

Re: (ITS#8797) improper use of gnutls causes segfault
by lukas＠selfnet.de 16 Jan '18

16 Jan '18

> PAM should be using nss-pam-ldapd, not calling libldap directly. This > is an architectural flaw in both GnuTLS and PAM, not an OpenLDAP bug. > This ITS is invalid. It's called _lib_ldap after all, so are other projects linking against / dlopen()ing libldap doing the wrong thing? Messing with other libraries global state and not undoing it on cleanup isn't exactly what a well-behaved library should do. The gnutls documentation explicitly mentions not to call gnutls_global_set_mutex from libraries: > Do not call this function from a library, or preferably from any > application unless really needed to.

1 0

Re: (ITS#8797) improper use of gnutls causes segfault
by lukas＠selfnet.de 16 Jan '18

16 Jan '18

> Removing the custom mutex functions and (for sufficiently recent GnuTLS) > the calls to gnutls_global_{,de}init() looks like a more and more > attractive solution. I am not aware of anyone using OpenLDAP with GnuTLS > on a platform for which GnuTLS lacks built-in mutex functions... Just for the record: I recompiled libldap with the call to gnutls_global_set_mutex removed and cups doesn't segfault anymore.

1 0

Re: (ITS#8797) improper use of gnutls causes segfault
by hyc＠symas.com 15 Jan '18

15 Jan '18

ryan(a)nardis.ca wrote: > On Mon, Jan 15, 2018 at 07:33:52PM +0000, lukas(a)selfnet.de wrote: >> During initialization, libldap sets custom gnutls mutex functions: >> https://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=blob;f=libraries… >> >> PAM uses libldap via dlopen and unloads it when it's done, but openldap doesn't >> undo gnutls_global_set_mutex, so any further calls to locking functions inside >> openldap will segfault since these function pointers now point to nowhere since >> openldap is unloaded. >> >> I encountered this issue in cups since cups uses gnutls itself for the web >> interface and segfaults when it uses gnutls after libldap. > > Thanks for this report. > > This is not the first issue caused by our usage of the custom mutex > functions; see also <https://bugs.debian.org/803197>. > > Removing the custom mutex functions and (for sufficiently recent GnuTLS) > the calls to gnutls_global_{,de}init() looks like a more and more > attractive solution. I am not aware of anyone using OpenLDAP with GnuTLS > on a platform for which GnuTLS lacks built-in mutex functions... PAM should be using nss-pam-ldapd, not calling libldap directly. This is an architectural flaw in both GnuTLS and PAM, not an OpenLDAP bug. This ITS is invalid. -- -- 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#8797) improper use of gnutls causes segfault
by ryan＠nardis.ca 15 Jan '18

15 Jan '18

On Mon, Jan 15, 2018 at 07:33:52PM +0000, lukas(a)selfnet.de wrote: >During initialization, libldap sets custom gnutls mutex functions: >https://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=blob;f=libraries… > >PAM uses libldap via dlopen and unloads it when it's done, but openldap doesn't >undo gnutls_global_set_mutex, so any further calls to locking functions inside >openldap will segfault since these function pointers now point to nowhere since >openldap is unloaded. > >I encountered this issue in cups since cups uses gnutls itself for the web >interface and segfaults when it uses gnutls after libldap. Thanks for this report. This is not the first issue caused by our usage of the custom mutex functions; see also <https://bugs.debian.org/803197>. Removing the custom mutex functions and (for sufficiently recent GnuTLS) the calls to gnutls_global_{,de}init() looks like a more and more attractive solution. I am not aware of anyone using OpenLDAP with GnuTLS on a platform for which GnuTLS lacks built-in mutex functions...

1 0

(ITS#8797) improper use of gnutls causes segfault
by lukas＠selfnet.de 15 Jan '18

15 Jan '18

Full_Name: Lukas K. Version: 2.4.44+dfsg-5+deb9u1 OS: Debian Stretch URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2001:7c7:2100:130:b9b5:f8df:7b98:8c2e) During initialization, libldap sets custom gnutls mutex functions: https://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=blob;f=libraries… PAM uses libldap via dlopen and unloads it when it's done, but openldap doesn't undo gnutls_global_set_mutex, so any further calls to locking functions inside openldap will segfault since these function pointers now point to nowhere since openldap is unloaded. I encountered this issue in cups since cups uses gnutls itself for the web interface and segfaults when it uses gnutls after libldap.

1 0

Re: (ITS#8766) Version 2.4.45 vulnerable - CVE-2017-14159
by quanah＠symas.com 15 Jan '18

15 Jan '18

Hi Muthamma, If you read the CVE and follow the link to the related OpenLDAP ITS, you will discover that the reported issue was marked invalid. I.e., what was reported is not a security vulnerability, or will it ever be fixed. Hope this helps! Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#8796) SASL bind resets SSF for subsequent binds
by ondra＠openldap.org 15 Jan '18

15 Jan '18

Full_Name: Ondrej Kuznik Version: master/re24 OS: URL: https://github.com/mistotebe/openldap/tree/ITS8796 Submission from: (NULL) (82.10.24.68) After the first bind, a second or any subsequent SASL bind on the same connection that requires non-zero SSF will fail since SSF isn't copied properly. See above for a patch.

1 0

Re: (ITS#8795) Authentication in database
by ryan＠nardis.ca 13 Jan '18

13 Jan '18

Hello, The ITS is for bug reports, not user support. For support, please contact the openldap-technical(a)openldap.org mailing list, or join the #openldap IRC channel. This ITS will be closed.

1 0

(ITS#8795) Authentication in database
by Bhade.j＠gmail.com 13 Jan '18

13 Jan '18

Full_Name: Jayant bhade Version: 3 OS: Ubuntu 14.4 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2405:204:9008:90a1::13dc:60ad) I'm new for ldap configuration. I getting error for authentication users. Additional info (13) user not found no secret in data base. Kindly help to resolve this problem.

1 0

(ITS#8794) Fix implicit function declaration warnings
by jamegerwe＠fake-box.com 29 Dec '17

29 Dec '17

Full_Name: Jame Gerwe Version: 2.4.45 OS: linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (88.198.125.96) If openldap gets compiled with -DLDAP_CONNECTIONLESS, then /libraries/libldap/open.c: In function ldap_initialize: /libraries/libldap/open.c:251:7: warning: implicit declaration of function ldap_is_ldapc_url [-Wimplicit-function-declaration] if (ldap_is_ldapc_url(url)) ^~~~~~~~~~~~~~~~~ Independent of -DLDAP_CONNECTIONLESS we also have complaints about pthread_{set,get}concurrency(): /libraries/libldap_r/thr_posix.c: In function ldap_pvt_thread_set_concurrency: /libraries/libldap_r/thr_posix.c:93:9: warning: implicit declaration of function pthread_setconcurrency [-Wimplicit-function-declaration] return pthread_setconcurrency( n ); ^~~~~~~~~~~~~~~~~~~~~~ /libraries/libldap_r/thr_posix.c: In function ldap_pvt_thread_get_concurrency: /libraries/libldap_r/thr_posix.c:107:9: warning: implicit declaration of function pthread_getconcurrency [-Wimplicit-function-declaration] return pthread_getconcurrency(); ^~~~~~~~~~~~~~~~~~~~~~ Although thr_posix.c includes (indirectly) pthread.h, the home of these two functions, they are not declared in the _DEFAULT_SOURCE set of pthread.h (of glibc). To declare them use #define _GNU_SOURCE or similar prior to including pthread.h. Suggested patch for the first warning: Add ldap_is_ldapc_url() to ldap.h and include it by open.c: -------- [PATCH] Fix implicit-function-declaration in open.c If LDAP_CONNECTIONLESS is defined, then open.c uses 'ldap_is_ldapc_url()' which is defined in url.c but not part of any API (neither public nor private). Make the function part of the public API in ldap.h and include ldap.h in open.c. diff a/include/ldap.h b/include/ldap.h --- a/include/ldap.h +++ b/include/ldap.h @@ -2041,6 +2041,12 @@ LDAP_F( int ) ldap_is_ldapi_url LDAP_P(( LDAP_CONST char *url )); +#ifdef LDAP_CONNECTIONLESS +LDAP_F( int ) +ldap_is_ldapc_url LDAP_P(( + LDAP_CONST char *url )); +#endif + LDAP_F( int ) ldap_url_parse LDAP_P(( LDAP_CONST char *url, diff a/libraries/libldap/open.c b/libraries/libldap/open.c --- a/libraries/libldap/open.c +++ b/libraries/libldap/open.c @@ -33,6 +33,7 @@ #include <ac/unistd.h> #include "ldap-int.h" +#include "ldap.h" #include "ldap_log.h" /* Caller must hold the conn_mutex since simultaneous accesses are possible */

1 0

ITS#8793
by i＠maskray.me 16 Dec '17

16 Dec '17

> Wrong. > Closing this ITS. Sorry but can you re-visit this please? Suppose a MDB_IDL points to [5, 9,7,5,3,1] where the first element denotes the number of elements. [-inf, 1) => position 6; the first element less than or equal to 1 does not exist, thus it points outside of the list [1,3) => position 5 [3,5) => position 4 [5,7) => position 3 [7,9) => position 2 [9,inf) => position 1 Thanks!

1 0

Re: (ITS#8793) [PATCH] Fix comment in lmdb: greater -> less
by hyc＠symas.com 16 Dec '17

16 Dec '17

i(a)maskray.me wrote: > Full_Name: Fangrui Song > Version: 2.4.45 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/fangrui-song-171216.patch > Submission from: (NULL) (24.130.65.8) > > > ID Lists are in decreasing order and the search algorithms actually find the > first ID less than or equal to the argument. Wrong. Closing this ITS. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#8793) [PATCH] Fix comment in lmdb: greater -> less
by i＠maskray.me 16 Dec '17

16 Dec '17

Full_Name: Fangrui Song Version: 2.4.45 OS: Linux URL: ftp://ftp.openldap.org/incoming/fangrui-song-171216.patch Submission from: (NULL) (24.130.65.8) ID Lists are in decreasing order and the search algorithms actually find the first ID less than or equal to the argument.

1 0

Re: (ITS#8759) mixed overlay nops & memberof cause segfault
by liuzx＠knownsec.com 15 Dec '17

15 Dec '17

IyBtb3JlIC9ldGMvb3BlbmxkYXAvc2xhcGQuY29uZg0KaW5jbHVkZSAgICAgICAgL2V0Yy9v cGVubGRhcC9zY2hlbWEvY29yZS5zY2hlbWENCmluY2x1ZGUgICAgICAgIC9ldGMvb3Blbmxk YXAvc2NoZW1hL2Nvc2luZS5zY2hlbWENCmluY2x1ZGUgICAgICAgIC9ldGMvb3BlbmxkYXAv c2NoZW1hL2luZXRvcmdwZXJzb24uc2NoZW1hDQppbmNsdWRlICAgICAgICAvZXRjL29wZW5s ZGFwL3NjaGVtYS9yZmMyMzA3YmlzLnNjaGVtYQ0KDQpwaWRmaWxlICAgICAgICAvcnVuL29w ZW5sZGFwL3NsYXBkLnBpZA0KYXJnc2ZpbGUgICAgICAgL3J1bi9vcGVubGRhcC9zbGFwZC5h cmdzDQoNCm1vZHVsZWxvYWQgICAgIG1lbWJlcm9mLnNvDQptb2R1bGVsb2FkICAgICBub3Bz LW92ZXJsYXkuc28NCg0KZGF0YWJhc2UgICAgICAgaGRiDQpzdWZmaXggICAgICAgICAibz1k ZW1vLGM9Y24iDQpyb290ZG4gICAgICAgICAiY249cm9vdCxvPWRlbW8sYz1jbiINCnJvb3Rw dyAgICAgICAgICIxMjM0NTYiDQpkaXJlY3RvcnkgICAgICAvdmFyL2xpYi9vcGVubGRhcC1k YXRhLw0KDQpvdmVybGF5IG1lbWJlcm9mDQptZW1iZXJvZi1ncm91cC1vYyBncm91cE9mTWVt YmVycw0KbWVtYmVyb2YtcmVmaW50ICAgdHJ1ZQ0KDQpvdmVybGF5IG5vcHMNCg0KIyBtb3Jl IC90bXAvMS5sZGlmDQpkbjogbz1kZW1vLGM9Y24NCm86IGRlbW8NCm9iamVjdENsYXNzOiBv cmdhbml6YXRpb24NCnN0cnVjdHVyYWxPYmplY3RDbGFzczogb3JnYW5pemF0aW9uDQoNCmRu OiBvdT1Hcm91cCxvPWRlbW8sYz1jbg0Kb2JqZWN0Q2xhc3M6IG9yZ2FuaXphdGlvbmFsVW5p dA0Kb3U6IEdyb3VwDQoNCmRuOiBvdT1QZW9wbGUsbz1kZW1vLGM9Y24NCm9iamVjdENsYXNz OiBvcmdhbml6YXRpb25hbFVuaXQNCm91OiBQZW9wbGUNCg0KZG46IG91PUxlYXZlLG89ZGVt byxjPWNuDQpvYmplY3RDbGFzczogb3JnYW5pemF0aW9uYWxVbml0DQpvdTogTGVhdmUNCg0K ZG46IHVpZD1saXV6eCxvdT1QZW9wbGUsbz1kZW1vLGM9Y24NCmdpZE51bWJlcjogMjAwMDAN Cm9iamVjdENsYXNzOiBwb3NpeEFjY291bnQNCm9iamVjdENsYXNzOiBpbmV0T3JnUGVyc29u DQpzdHJ1Y3R1cmFsT2JqZWN0Q2xhc3M6IGluZXRPcmdQZXJzb24NCnVpZE51bWJlcjogMTAw MDANCnVpZDogbGl1engNCmhvbWVEaXJlY3Rvcnk6IC9ob21lL3VzZXJzL2xpdXp4DQpzbjog TGl1DQpjbjogWi4gTGl1DQptZW1iZXJPZjogY249dXNlcnMsb3U9R3JvdXAsbz1kZW1vLGM9 Y24NCm1vYmlsZTogMTM5MTA4MjM0NzUNCg0KZG46IGNuPXVzZXJzLG91PUdyb3VwLG89ZGVt byxjPWNuDQpvYmplY3RDbGFzczogZ3JvdXBPZk1lbWJlcnMNCmNuOiB1c2Vycw0KbWVtYmVy OiB1aWQ9bGl1engsb3U9UGVvcGxlLG89ZGVtbyxjPWNuDQoNCiMgc3VkbyAtdSBsZGFwIHNs YXBhZGQgLWwgMS5sZGlmDQojIHNlcnZpY2Ugc2xhcGQgc3RhcnQNCiMgcHMgfCBncmVwIHNs YXBkICMgY29uZmlybSBzbGFwZCBpcyBydW5uaW5nDQojIG1vcmUgfi90LmxkaWYNCmRuOiB1 aWQ9bGl1engsb3U9UGVvcGxlLG89ZGVtbyxjPWNuDQpjaGFuZ2V0eXBlOiBtb2Rkbg0KbmV3 cmRuOiB1aWQ9bGl1engNCmRlbGV0ZW9sZHJkbjogMQ0KbmV3c3VwZXJpb3I6IG91PUxlYXZl LG89ZGVtbyxjPWNuDQoNCiMgbGRhcG1vZGlmeSAtSCBsZGFwOi8vMTI3LjAuMC4xIC1EICdj bj1yb290LG89ZGVtbyxjPWNuJyAtdyAxMjM0NTYgIC1mIHQubGRpZg0KbW9kaWZ5aW5nIHJk biBvZiBlbnRyeSAidWlkPWxpdXp4LG91PVBlb3BsZSxvPWRlbW8sYz1jbiINCmxkYXBfcmVz dWx0OiBDYW4ndCBjb250YWN0IExEQVAgc2VydmVyICgtMSkNCg0KIyBwcyB8IGdyZXAgc2xh cGQgIyBjb25maXJtIHNsYXBkIGlzIGdvbmUNCg0Kc29tZXRpbWVzIGRtZXNnIGNhbiBzZWUg a2VybmVsIGxvZzoNCnRyYXBzOiBzbGFwZFsyNTU2MF0gZ2VuZXJhbCBwcm90ZWN0aW9uIGlw OjdmYWJmNjBiMGU3MiBzcDo3ZmFiZDk2OWJmZDAgZXJyb3I6MCBpbiBsaWJjLTIuMjMuc29b N2ZhYmY2MDY4MDAwKzE5ZjAwMF0NCnNsYXBkWzI2NDM3XTogc2VnZmF1bHQgYXQgNzM3MjY1 NjI2ZDgxIGlwIDAwMDAwMDAwMDA0YWE0ZDAgc3AgMDAwMDdmNjNjMmM3OTcxMCBlcnJvciA0 IGluIHNsYXBkWzQwMDAwMCsxNWEwMDBd

1 0

Re: (ITS#8791) OpenSSL 1.1.1 compat issue
by bbaetz＠google.com 15 Dec '17

15 Dec '17

--94eb2c05eb72af425f056056a2cc Content-Type: text/plain; charset="UTF-8" Done in ftp://ftp.openldap.org/incoming/bradley-baetz-20171215.patch On Fri, 15 Dec 2017 at 04:36 Howard Chu <hyc(a)symas.com> wrote: > bbaetz(a)google.com wrote: > > Full_Name: Bradley Baetz > > Version: 2.4.45 > > OS: linux > > URL: ftp://ftp.openldap.org/incoming/bradley-baetz-20171214.patch > > Submission from: (NULL) (2401:fa00:9:11:7ac0:58b5:299c:bebb) > > Thanks for the patch. The initialization of the static tlso_bio_method is > racy. One-time initializations should be done in tlso_init, and the > allocated > memory should be freed in tlso_destroy. > > > > > ITS#8533 added support for the OpenSSL's hiding of the bio_method_st > struct. > > > > However, it did this by re-defining the now-private structure, using the > OpenSSL > > 1.0 version. That will fail when OpenSSL changes their structure, which > they > > have already done for v1.1.1 - see > > > https://git.openssl.org/gitweb/?p=openssl.git;a=blob;f=include/internal/bio… > > > > It also fails with BoringSSL, which has v1.0's OPENSSL_VERSION_NUMBER > define, > > but has not yet hidden the struct definition. > > > > The attached file is derived from OpenLDAP Software. All of the > modifications to > > OpenLDAP Software represented in the following patch(es) were developed > by > > Google, LLC. Google, LLC has not assigned rights and/or interest in this > work to > > any party. I, Bradley Baetz am authorized by Google, LLC, my employer, to > > release this work under the following terms. > > > > The attached modifications to OpenLDAP Software are subject to the > following > > notice: > > Copyright 2017 Google, LLC. > > Redistribution and use in source and binary forms, with or without > modification, > > are permitted only as authorized by the OpenLDAP Public License. > > > > > > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ > --94eb2c05eb72af425f056056a2cc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><span style=3D"font-size:small">Done in=C2=A0</span><a hre= f=3D"ftp://ftp.openldap.org/incoming/bradley-baetz-20171215.patch" style=3D= "font-size:small">ftp://ftp.openldap.org/incoming/bradley-baetz-20171215.pa= tch</a><br><br class=3D"inbox-inbox-Apple-interchange-newline"></div><br><d= iv class=3D"gmail_quote"><div dir=3D"ltr">On Fri, 15 Dec 2017 at 04:36 Howa= rd Chu <<a href=3D"mailto:hyc@symas.com">hyc(a)symas.com</a>> wrote:<br= ></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-= left:1px #ccc solid;padding-left:1ex"><a href=3D"mailto:bbaetz@google.com" = target=3D"_blank">bbaetz(a)google.com</a> wrote:<br> > Full_Name: Bradley Baetz<br> > Version: 2.4.45<br> > OS: linux<br> > URL: <a href=3D"ftp://ftp.openldap.org/incoming/bradley-baetz-20171214= .patch" rel=3D"noreferrer" target=3D"_blank">ftp://ftp.openldap.org/incomin= g/bradley-baetz-20171214.patch</a><br> > Submission from: (NULL) (2401:fa00:9:11:7ac0:58b5:299c:bebb)<br> <br> Thanks for the patch. The initialization of the static tlso_bio_method is<b= r> racy. One-time initializations should be done in tlso_init, and the allocat= ed<br> memory should be freed in tlso_destroy.<br> <br> ><br> > ITS#8533 added support for the OpenSSL's hiding of the bio_method_= st struct.<br> ><br> > However, it did this by re-defining the now-private structure, using t= he OpenSSL<br> > 1.0 version. That will fail when OpenSSL changes their structure, whic= h they<br> > have already done for v1.1.1 - see<br> > <a href=3D"https://git.openssl.org/gitweb/?p=3Dopenssl.git;a=3Dblob;f= =3Dinclude/internal/bio.h;hb=3De1dd8fa00a1e06d27c8b024dac7657a8d8a9b451#l16= " rel=3D"noreferrer" target=3D"_blank">https://git.openssl.org/gitweb/?p=3D= openssl.git;a=3Dblob;f=3Dinclude/internal/bio.h;hb=3De1dd8fa00a1e06d27c8b02= 4dac7657a8d8a9b451#l16</a><br> ><br> > It also fails with BoringSSL, which has v1.0's OPENSSL_VERSION_NUM= BER define,<br> > but has not yet hidden the struct definition.<br> ><br> > The attached file is derived from OpenLDAP Software. All of the modifi= cations to<br> > OpenLDAP Software represented in the following patch(es) were develope= d by<br> > Google, LLC. Google, LLC has not assigned rights and/or interest in th= is work to<br> > any party. I, Bradley Baetz am authorized by Google, LLC, my employer,= to<br> > release this work under the following terms.<br> ><br> > The attached modifications to OpenLDAP Software are subject to the fol= lowing<br> > notice:<br> > Copyright 2017 Google, LLC.<br> > Redistribution and use in source and binary forms, with or without mod= ification,<br> > are permitted only as authorized by the OpenLDAP Public License.<br> ><br> ><br> <br> <br> --<br> =C2=A0 =C2=A0-- Howard Chu<br> =C2=A0 =C2=A0CTO, Symas Corp.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<a hr= ef=3D"http://www.symas.com" rel=3D"noreferrer" target=3D"_blank">http://www= .symas.com</a><br> =C2=A0 =C2=A0Director, Highland Sun=C2=A0 =C2=A0 =C2=A0<a href=3D"http://hi= ghlandsun.com/hyc/" rel=3D"noreferrer" target=3D"_blank">http://highlandsun= .com/hyc/</a><br> =C2=A0 =C2=A0Chief Architect, OpenLDAP=C2=A0 <a href=3D"http://www.openldap= .org/project/" rel=3D"noreferrer" target=3D"_blank">http://www.openldap.org= /project/</a><br> </blockquote></div> --94eb2c05eb72af425f056056a2cc--

1 0

Re: (ITS#8791) OpenSSL 1.1.1 compat issue
by hyc＠symas.com 14 Dec '17

14 Dec '17

bbaetz(a)google.com wrote: > Full_Name: Bradley Baetz > Version: 2.4.45 > OS: linux > URL: ftp://ftp.openldap.org/incoming/bradley-baetz-20171214.patch > Submission from: (NULL) (2401:fa00:9:11:7ac0:58b5:299c:bebb) Thanks for the patch. The initialization of the static tlso_bio_method is racy. One-time initializations should be done in tlso_init, and the allocated memory should be freed in tlso_destroy. > > ITS#8533 added support for the OpenSSL's hiding of the bio_method_st struct. > > However, it did this by re-defining the now-private structure, using the OpenSSL > 1.0 version. That will fail when OpenSSL changes their structure, which they > have already done for v1.1.1 - see > https://git.openssl.org/gitweb/?p=openssl.git;a=blob;f=include/internal/bio… > > It also fails with BoringSSL, which has v1.0's OPENSSL_VERSION_NUMBER define, > but has not yet hidden the struct definition. > > The attached file is derived from OpenLDAP Software. All of the modifications to > OpenLDAP Software represented in the following patch(es) were developed by > Google, LLC. Google, LLC has not assigned rights and/or interest in this work to > any party. I, Bradley Baetz am authorized by Google, LLC, my employer, to > release this work under the following terms. > > The attached modifications to OpenLDAP Software are subject to the following > notice: > Copyright 2017 Google, LLC. > Redistribution and use in source and binary forms, with or without modification, > are permitted only as authorized by the OpenLDAP Public License. > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#8791) OpenSSL 1.1.1 compat issue
by bbaetz＠google.com 13 Dec '17

13 Dec '17

Full_Name: Bradley Baetz Version: 2.4.45 OS: linux URL: ftp://ftp.openldap.org/incoming/bradley-baetz-20171214.patch Submission from: (NULL) (2401:fa00:9:11:7ac0:58b5:299c:bebb) ITS#8533 added support for the OpenSSL's hiding of the bio_method_st struct. However, it did this by re-defining the now-private structure, using the OpenSSL 1.0 version. That will fail when OpenSSL changes their structure, which they have already done for v1.1.1 - see https://git.openssl.org/gitweb/?p=openssl.git;a=blob;f=include/internal/bio… It also fails with BoringSSL, which has v1.0's OPENSSL_VERSION_NUMBER define, but has not yet hidden the struct definition. The attached file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Google, LLC. Google, LLC has not assigned rights and/or interest in this work to any party. I, Bradley Baetz am authorized by Google, LLC, my employer, to release this work under the following terms. The attached modifications to OpenLDAP Software are subject to the following notice: Copyright 2017 Google, LLC. Redistribution and use in source and binary forms, with or without modification, are permitted only as authorized by the OpenLDAP Public License.

1 0

(ITS#8790) N-Way MMR w/o serverID in at least one entry causes REFRESH
by quanah＠openldap.org 12 Dec '17

12 Dec '17

Full_Name: Quanah Gibson-Mount Version: 2.4.45 OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.148.239) If one has configured N-WAY MMR in such a fashion that only one master ever gets the write ops (whether this is mirrormode or other methodologies), and there are zero entries in the database with an entryCSN of the other masters in the system, attempts to bring those other masters back up will result in a REFRESH phase on those masters, and potentially destabilize the entire cluster (See ITS#8789 for example). To avoid this, we should document that best practice involves having one object per master that is only ever modified by that master, so there is always a minimum of one object in the database with a CSN matching that master. This should avoid the REFRESH issue when bringing up a failed master.

1 0

(ITS#8789) syncrepl fallback can destabilize delta-sync MMR nodes
by quanah＠openldap.org 11 Dec '17

11 Dec '17

Full_Name: Quanah Gibson-Mount Version: 2.4.45 OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.148.239) In a N-Way MMR setup, one node falling back to syncrepl REFRESH may destabilize other nodes, as it will incorrectly record changes it is receiving from the master that has write ops. If another node is using this master for its source, it will then be forced into fallback as well, further destabilizing the cluster. In the scenario above, triggered this via a 4-way MMR setup. serverID 1 master was the only master that had write ops. serverid 3 went into REFRESH for unknown reasons. serverid 2 was using serverid3 to pull in the changes for serverid 1, for unknown reasons. serverid 1 recorded the following change: dn: reqStart=20171206214129.000002Z,cn=accesslog objectClass: auditModify structuralObjectClass: auditModify reqStart: 20171206214129.000002Z reqEnd: 20171206214129.000003Z reqType: modify reqSession: 2209 reqAuthzID: cn=ldaproot,dc=xxx,dc=edu reqDN: uid=cdxxxxx,ou=user,dc=xxx,dc=edu reqResult: 0 reqMod: pwdAccountLockedTime:= 20171206214129Z reqMod: pwdFailureTime:+ 20171206214129.121729Z reqMod: entryCSN:= 20171206214129.121794Z#000000#001#000000 reqMod: modifiersName:= cn=ldaproot,dc=xxx,dc=edu reqMod: modifyTimestamp:= 20171206214129Z reqEntryUUID: 41e02340-18f9-1027-900a-8ac8742d2008 entryUUID: f66c9be6-6f19-1037-9821-a35b555092e3 creatorsName: cn=accesslog createTimestamp: 20171206214129Z entryCSN: 20171206214129.121794Z#000000#001#000000 modifiersName: cn=accesslog modifyTimestamp: 20171206214129Z However, serverID 3 records the following for this same CSN instead: dn: reqStart=20171206214354.000006Z,cn=accesslog objectClass: auditModify structuralObjectClass: auditModify reqStart: 20171206214354.000006Z reqEnd: 20171206214354.000008Z reqType: modify reqSession: 1 reqAuthzID: cn=ldaproot,dc=xxx,dc=edu reqDN: uid=cdxxxxx,ou=user,dc=xxx,dc=edu reqResult: 0 reqMod: userPassword:- reqMod: pwdFailureTime:+ 20171206214105.339881Z reqMod: pwdFailureTime:+ 20171206214105.504629Z reqMod: pwdFailureTime:+ 20171206214105.756105Z reqMod: pwdFailureTime:+ 20171206214106.117063Z reqMod: pwdFailureTime:+ 20171206214106.348441Z reqMod: pwdFailureTime:+ 20171206214106.575907Z reqMod: pwdFailureTime:+ 20171206214106.875082Z reqMod: pwdFailureTime:+ 20171206214107.175699Z reqMod: pwdFailureTime:+ 20171206214107.655344Z reqMod: pwdFailureTime:+ 20171206214107.915930Z reqMod: pwdFailureTime:+ 20171206214108.156601Z reqMod: pwdFailureTime:+ 20171206214108.431242Z reqMod: pwdFailureTime:+ 20171206214108.791469Z reqMod: pwdFailureTime:+ 20171206214109.033924Z reqMod: pwdFailureTime:+ 20171206214109.318285Z reqMod: pwdFailureTime:+ 20171206214109.565585Z reqMod: pwdFailureTime:+ 20171206214109.823744Z reqMod: pwdFailureTime:+ 20171206214110.110372Z reqMod: pwdFailureTime:+ 20171206214110.306955Z reqMod: pwdFailureTime:+ 20171206214110.638527Z reqMod: pwdFailureTime:+ 20171206214111.014705Z reqMod: pwdFailureTime:+ 20171206214111.370965Z reqMod: pwdFailureTime:+ 20171206214111.673694Z reqMod: pwdFailureTime:+ 20171206214112.011806Z reqMod: pwdFailureTime:+ 20171206214112.327727Z reqMod: pwdFailureTime:+ 20171206214112.584305Z reqMod: pwdFailureTime:+ 20171206214112.930555Z reqMod: pwdFailureTime:+ 20171206214113.269235Z reqMod: pwdFailureTime:+ 20171206214113.633844Z reqMod: pwdFailureTime:+ 20171206214113.928111Z reqMod: pwdFailureTime:+ 20171206214114.217342Z reqMod: pwdFailureTime:+ 20171206214114.539026Z reqMod: pwdFailureTime:+ 20171206214114.888149Z reqMod: pwdFailureTime:+ 20171206214115.262042Z reqMod: pwdFailureTime:+ 20171206214115.675217Z reqMod: pwdFailureTime:+ 20171206214116.030024Z reqMod: pwdFailureTime:+ 20171206214116.362739Z reqMod: pwdFailureTime:+ 20171206214116.616784Z reqMod: pwdFailureTime:+ 20171206214116.987779Z reqMod: pwdFailureTime:+ 20171206214117.293091Z reqMod: pwdFailureTime:+ 20171206214117.549392Z reqMod: pwdFailureTime:+ 20171206214117.838969Z reqMod: pwdFailureTime:+ 20171206214118.051355Z reqMod: pwdFailureTime:+ 20171206214118.275629Z reqMod: pwdFailureTime:+ 20171206214118.583510Z reqMod: pwdFailureTime:+ 20171206214118.866746Z reqMod: pwdFailureTime:+ 20171206214119.174928Z reqMod: pwdFailureTime:+ 20171206214119.483218Z reqMod: pwdFailureTime:+ 20171206214119.929568Z reqMod: pwdFailureTime:+ 20171206214120.147090Z reqMod: pwdFailureTime:+ 20171206214120.549317Z reqMod: pwdFailureTime:+ 20171206214120.869798Z reqMod: pwdFailureTime:+ 20171206214121.143126Z reqMod: pwdFailureTime:+ 20171206214121.476740Z reqMod: pwdFailureTime:+ 20171206214121.799935Z reqMod: pwdFailureTime:+ 20171206214122.066816Z reqMod: pwdFailureTime:+ 20171206214122.405710Z reqMod: pwdFailureTime:+ 20171206214122.761880Z reqMod: pwdFailureTime:+ 20171206214123.032806Z reqMod: pwdFailureTime:+ 20171206214123.280540Z reqMod: pwdFailureTime:+ 20171206214123.748973Z reqMod: pwdFailureTime:+ 20171206214124.085579Z reqMod: pwdFailureTime:+ 20171206214124.340470Z reqMod: pwdFailureTime:+ 20171206214124.638673Z reqMod: pwdFailureTime:+ 20171206214124.970374Z reqMod: pwdFailureTime:+ 20171206214125.302162Z reqMod: pwdFailureTime:+ 20171206214125.630451Z reqMod: pwdFailureTime:+ 20171206214125.921736Z reqMod: pwdFailureTime:+ 20171206214126.232407Z reqMod: pwdFailureTime:+ 20171206214126.564006Z reqMod: pwdFailureTime:+ 20171206214126.816303Z reqMod: pwdFailureTime:+ 20171206214127.168459Z reqMod: pwdFailureTime:+ 20171206214127.481267Z reqMod: pwdFailureTime:+ 20171206214127.779584Z reqMod: pwdFailureTime:+ 20171206214128.176611Z reqMod: pwdFailureTime:+ 20171206214128.429982Z reqMod: pwdFailureTime:+ 20171206214128.852280Z reqMod: pwdFailureTime:+ 20171206214129.121729Z reqMod: pwdAccountLockedTime:= 20171206214129Z reqMod: entryCSN:= 20171206214129.121794Z#000000#001#000000 reqMod: modifiersName:= cn=ldaproot,dc=xxx,dc=edu reqMod: modifyTimestamp:= 20171206214129Z reqMod: pwdFailureTime:- reqEntryUUID: 41e02340-18f9-1027-900a-8ac8742d2008 entryCSN: 20171206214129.121794Z#000000#001#000000 entryUUID: 4d10f56e-6f1a-1037-9a98-f5e2e6dad8c2 creatorsName: cn=accesslog createTimestamp: 20171206214129Z modifiersName: cn=accesslog modifyTimestamp: 20171206214129Z serverID2 is then unable to process the change for this CSN provided by serverID3, and goes into refresh mode.

1 0

Re: (ITS#8788) slapd-pcache undef not compatible with mdb
by hyc＠symas.com 11 Dec '17

11 Dec '17

quanah(a)openldap.org wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.45 > OS: N/A > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (47.208.148.239) > > > The pcache backend to slapd has the option for attr sets to note if an attribute > that being cached is not defined in the local schema by prefixing it with > "undef:", such as "undef:myattr". While this functionality works fine when > pcache is using back-bdb or back-hdb, it does not work with back-mdb. In the > case where back-mdb is used, an error will be logged if the hidden "pcaache" > loglevel is used, but it will still attempt to answer queries (it will return no > results, but with a success return code). pcache uses slap_bv2tmp_ad() to register undef attributes. It looks like there's a bug here in that it doesn't initialize ad->ad_index. (bv2undef initializes this to zero.) Of course, that still doesn't change the fact that back-mdb requires schema to be fully defined. > At a minimum, the documentation needs to be updated to note this feature > incompatibility. It would be additionally useful if either slapd would refuse > to start if undef was used on top of back-mdb, or pcache would log an error that > it could not answer the result from the cache, and fall back to doing a direct > lookup. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#8788) slapd-pcache undef not compatible with mdb
by quanah＠openldap.org 11 Dec '17

11 Dec '17

Full_Name: Quanah Gibson-Mount Version: 2.4.45 OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.148.239) The pcache backend to slapd has the option for attr sets to note if an attribute that being cached is not defined in the local schema by prefixing it with "undef:", such as "undef:myattr". While this functionality works fine when pcache is using back-bdb or back-hdb, it does not work with back-mdb. In the case where back-mdb is used, an error will be logged if the hidden "pcaache" loglevel is used, but it will still attempt to answer queries (it will return no results, but with a success return code). At a minimum, the documentation needs to be updated to note this feature incompatibility. It would be additionally useful if either slapd would refuse to start if undef was used on top of back-mdb, or pcache would log an error that it could not answer the result from the cache, and fall back to doing a direct lookup.

1 0

(ITS#8787) mkdep does not get CFLAGS during cross compilation
by jinxinliang＠yahoo.com 09 Dec '17

09 Dec '17

Full_Name: Jeremy Jin Version: 2.4 OS: mingw and ubuntu URL: Submission from: (NULL) (209.29.4.43) I am trying to build mingw in two different situations, 1. on mingw 2. cross build from ubuntu 14 for target arm linux In both situation I found that, some dependencies (such as regex) does not exist in system default /usr/include. So I download regex from somewhere and build it. Then I need to specify a custom CFLAGS for configure command such as below ./configure CFLAGS=-I/home/user1/include LDFLAGS=-L/home/user1/lib LIBS=-lregex the configuration run successfully,then I proceed to do "make depend". However it will report "regex.h" file not found. And I found that "mkdep" command does not make use of the CFLAGS I provided on configure command at all. I worked around it by create another mkdep command to wrap the existing mkdep command and add my additional include folders and it worked. Then next issue I found is I had to modify "portable.h" file as well. I had to comment out "#define socklen_t int" and add "typedef unsigned int uint32_t". I am not sure why the portable.h is not generated correctly (this only happens on mingw, not tested on ubuntu cross compiling ARM at all).

1 0

Re: (ITS#8784) SIGBUS in mdb_page_touch
by hyc＠symas.com 08 Dec '17

08 Dec '17

balaret(a)gmail.com wrote: > Full_Name: Sergey Z > Version: LMDB_0.9.19 > OS: Android > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (2620:119:5001:2242:9215:2763:ff1b:ae35) > > > Hey guys, > > We are using LMDB 0.9.19 in our Android project and sometimes we are getting > SIGBUS in mdb_page_touch(). We can't reproduce this issue on our side but we > have plenty of crash reports from our users (about 400 daily): > > SIGBUS > libLMDBAndroid.so.mdb_page_touch ( mdb .c :2412) > libLMDBAndroid.so.mdb_page_search ( mdb .c :5610) > libLMDBAndroid.so.mdb_freelist_save ( mdb .c :3128) > libLMDBAndroid.so.mdb_txn_commit ( mdb .c :3606) > > This is probably a platform specific issue because 95% of crashes happened on > Android 7.0. > > I would greatly appreciate if you help to shed a light on this - any ideas what > might goes wrong or what might cause such an issue. I've encountered this as well. I believe there's a bug in the Android FUSE filesystem driver. Every time I've analyzed one of these crashes in the debugger, the relevant addresses are perfectly valid, which leads me to believe there's a race condition in their page fault handler. I.e., eventually the handler returns a valid memory page but the application has been killed before the handler completes. Then, by the time the debugger gets control, all of memory looks valid. If you root the device and mount the storage partition directly, bypassing the Android FUSE filesystem, you'll find that these crashes all disappear - even if using the same storage device as before. Which again points to a bug in their FUSE filesystem driver. But I haven't been able to pinpoint the bug in their FUSE driver source code yet. I suggest you focus your debugging efforts there. > > Thank you, > Sergey > > -- -- 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#8429) deadlock on a modification operation with replication
by quanah＠symas.com 08 Dec '17

08 Dec '17

--On Thursday, May 19, 2016 12:31 PM +0000 elecharny(a)apache.org wrote: > Full_Name: Emmanuel Lecharny > Version: 2.4.44 > OS: Linux CentOS 6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (92.169.142.218) This should be fixed now, tracked under ITS#8752. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8786) Allow OpenLDAP to start as non-root
by hyc＠symas.com 08 Dec '17

08 Dec '17

akram.benaissi(a)gmail.com wrote: > Full_Name: Akram Ben Aissi > Version: 1.1.10 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (77.154.204.242) > > > Hi, > > We want to run OpenLDAP in containers without root privilege, nor root user id. > Actually, we start it with user uid=100000009, gid=0 > And we do proper chgrp 0 and chmod 0770 on require directories. > > Because of this: https://github.com/winlibs/openldap/blob/master/servers/slapd/user.c#L158 > > we have that: > Could not set real user id to 100000009 > > It would be better to check that setuid is required only if asked user is > different from actual user. > > Does it make sense ? No. Just start slapd without specifying a userID. Closing this ITS. -- -- 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#8785) Password quality/Strength check
by michael＠stroeder.com 08 Dec '17

08 Dec '17

This is a cryptographically signed message in MIME format. --------------ms020404010102000204010800 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable kashyap_sunita(a)ongc.co.in wrote: > We have successfully implemented existing password policy in our DIT bu= t the > most required feature of password strength is missing in existing overl= ay.=20 > Can you suggest that how we could implement password quality/strength i= n this > version of openldap. The ITS is for reporting bug only. Please post usage questions to openldap-technical mailing list where you reach more recipients. So others can answer and learn as well. https://www.openldap.org/lists/ Ciao, Michael. --------------ms020404010102000204010800 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CucwggT9MIID5aADAgECAhBFRleVrRF8X5GwbV0tcLCgMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwOTE2MDcxNjUxWhcNMTkxMjE2MDcxNjUxWjBEMR0wGwYDVQQDDBRtaWNo YWVsQHN0cm9lZGVyLmNvbTEjMCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRlci5jb20w ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQChMBt5jtuLXsNQ5U7rBbZit8sknIwz hfaousT3d/fssQ6qZwe9l1yklILSXVMqI7/bxbiqcd3zrz+imdSlZPrFBHGfh04DZHCfss2F RwSswGejqP1qE3hPvZi96wFfOMqenpN+pSXqNJ1OPBCJ8a+8ZEioFKoEj3HkCCXjbmezAgms FuA7aFE9BfjJ2eQKw8B9G8X1FjvOTinYSZ2F+qHpKgywl4HTx0dMnYy+Pwu4DDIHkEaVH+uj K1/ed76WUEH51mX9m2Xu0onfQlSM3me6EvAAZiIDsCEbF9WttRuJbpfCFo0m2uW7BBugS7EG Jro1nRSQVnpJyTFgHb5EGMVVAgMBAAGjggG4MIIBtDAOBgNVHQ8BAf8EBAMCBLAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYDVR0OBBYEFFh1801TSuxT Nltnv9rOjrZzUUgNMB8GA1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUnSG1oMG8GCCsGAQUF BwEBBGMwYTAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29tMDkGCCsGAQUF BzAChi1odHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5jcnQwOAYD VR0fBDEwLzAtoCugKYYnaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEuY3Js MB8GA1UdEQQYMBaBFG1pY2hhZWxAc3Ryb2VkZXIuY29tMCMGA1UdEgQcMBqGGGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tLzBHBgNVHSAEQDA+MDwGCysGAQQBgbU3AQIFMC0wKwYIKwYBBQUH AgEWH2h0dHBzOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kwDQYJKoZIhvcNAQELBQADggEB AKiJ9wpjJeHdEzHDZyqmhn4cHcRj9Ag7ZQK0meq1N3oQ9M1YeVge6vZe20LXojgXsNUQGLSt 1lW2s7fABkL9CF+/RtWznHxlp4YpWX/RgbHBo3uXKNA5JUOjbxQ2+1b1jaTp/FUrSIISAxgd RpeYAODJ0db1x8Q+l66DtIVjj7ktWISdJWE2Opn4QnaRwdj6n35Rul4S2ikUsmxtGrHLpjRR XJqbsGa0RZdJyUKlZ2ZRAoRz4jKHOogQcig937sR5Ut2pGOhrScEhgARY2c8Gs2olRTL3pue mE4vjY0g1Nwr9RzeFwMuasiFh4yD34i6jIRfoNzuLPgydjsJ0grw0akwggXiMIIDyqADAgEC AhBrp4p9CteI1lEK+Vnk57ThMA0GCSqGSIb3DQEBCwUAMH0xCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAe Fw0xNTEyMTYwMTAwMDVaFw0zMDEyMTYwMTAwMDVaMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhv cml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQC9fdr3w6J9g/Zbgv3bW1+uHht1wLUZr5gkrLtXedg17Ake fMyUGwrQdvwObhajcVmnKVxhrUwkZPXRAwZZosRHfEIi5FH7x6SV/8Sp5lZEuiMnvMFG2MzL A84J6Ws5T4NfXZ0qn4TPgnr3X2vPVS51M7Ua9nIJgn8jvTra4eyyQzxvuA/GZwKg7VQfDCmC S+kICslYYWgXOMt2xlsSslxLce0CGWRsT8EpMyt1iDflSjXZIsE7m1uTyHaKZspMLyIyz6my Su8j8BWWHpChNNeTrFuhVfrOAyDPFJVUvKZCLKBhibTLloyy+LatoWELrjdI4a8StZY8+dIR 9t4APXGzAgMBAAGjggFkMIIBYDAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0lBBYwFAYIKwYBBQUH AwIGCCsGAQUFBwMEMBIGA1UdEwEB/wQIMAYBAf8CAQAwMgYDVR0fBCswKTAnoCWgI4YhaHR0 cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMGYGCCsGAQUFBwEBBFowWDAkBggrBgEF BQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29tMDAGCCsGAQUFBzAChiRodHRwOi8vYWlh LnN0YXJ0c3NsLmNvbS9jZXJ0cy9jYS5jcnQwHQYDVR0OBBYEFCSBbDlhvkkPj7cbRivJKLUn SG1oMB8GA1UdIwQYMBaAFE4L7xqkQFulF2mHMMo0aEPQQa7yMD8GA1UdIAQ4MDYwNAYEVR0g ADAsMCoGCCsGAQUFBwIBFh5odHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kwDQYJKoZI hvcNAQELBQADggIBAIvj94fsAYuErQ8BAluc4SMnIwS9NPBwAm5SH9uh2NCXTq7im61g7F1L IiNI/+wq37fUuaMbz4g7VarKQTgf8ubs0p7NZWcIe7Bvem2AWaXBsxsaRTYw5kG3DN8pd1hS EUuFoTa7DmNeFe8tiK1BrL3rbA/m48jp4AiFXgvxprJrW7izsyetOrRHPbkW4Y07v29MdhaP v3u1JELyszXqOzjIYo4sWlC8iDQXwgSW/ntvWy2n4LuiaozlCfXl149tKeqvwlvrla2Yklue /quWp9j9ou4T/OY0CXMuY+B8wNK0ohd2D4ShgFlMSjzAFRoHGKF81snTr2d1A7Ew02oF6UQy CkC2aNNsK5cWOojBar5c7HplX9aHYUCZouxIeU28SONJAxnATgR4cJ2jrpmYSz/kliUJ46S6 UpVDo/ebn9c6PaM/XtDYCCaM/7XX6wc3s++sbQ7CtCn1Ax7df6ufQbwyO0V+oFa9H0KAsjHM zcwk3EV2B2NLatidKE/m7G+rB9m+FlVgIiSp0mGlg43QO9Kh1+JqvTCIzv2bJJkmPMLQJNuK KwHNL8F4GGp6jbAV+WL+LDeGfVcq8DHS3LrD+xyYEXQBiqZEdiPVOMxLDSUCXsDO0uCWpaNQ 8j6y6S9p0xE/Ga0peVLadVHhqf9nXqKaxnr358VgfrxzUIrvOaOjMYIDzDCCA8gCAQEwgYkw dTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0 Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAx IENsaWVudCBDQQIQRUZXla0RfF+RsG1dLXCwoDANBglghkgBZQMEAgEFAKCCAhMwGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcxMjA4MTA1MTE5WjAvBgkq hkiG9w0BCQQxIgQgcivLnD1qr1O+sbnbgTzcTC7OBlvjiiJA47PQEaHC9HAwbAYJKoZIhvcN AQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBmgYJKwYB BAGCNxAEMYGMMIGJMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkw JwYDVQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3Rh cnRDb20gQ2xhc3MgMSBDbGllbnQgQ0ECEEVGV5WtEXxfkbBtXS1wsKAwgZwGCyqGSIb3DQEJ EAILMYGMoIGJMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYD VQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRD b20gQ2xhc3MgMSBDbGllbnQgQ0ECEEVGV5WtEXxfkbBtXS1wsKAwDQYJKoZIhvcNAQEBBQAE ggEAGHRmJV2ToBGfFpRVMZDu0TVUdJwApUWjXa5oDYAw6yk1QqNtIWHXJWSIl1shNN4REHod 72z4OvN7bQYJShoniiK/adWekwzB4ynXDmLlYWaasnbI5vi72SEPU6gRKOSVZqSBzuxdxYtc bqSiIOEBJHLuQbQwE7Drf6WD44cIEdK8vOiPl2wRSmJb9oR7CmowmEMWioCkBhu/aeWDXqi0 uEHWcGG6+fP1n8C5V/EH/fPX6lmdpnV3iakpGkkNJC8BMJ+COJ2hZekplAWPThNZrAoWntln UKxedySSpSX0Q6xGmDynG2jepyFEzAUOSaOBGGZoYD6pJfbUi5K0Qz69MgAAAAAAAA== --------------ms020404010102000204010800--

1 0

Re: (ITS#8786) Allow OpenLDAP to start as non-root
by michael＠stroeder.com 08 Dec '17

08 Dec '17

This is a cryptographically signed message in MIME format. --------------ms040106020009060205040508 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable akram.benaissi(a)gmail.com wrote: > We want to run OpenLDAP in containers without root privilege, nor root = user id. > Actually, we start it with user uid=3D100000009, gid=3D0 AFAICT and independent of OpenLDAP's slapd allowing an arbitrary uid to use gid=3D0 would be an unauthorized privilege escalation / security hole= =2E Why don't you use the primary gid of uid=3D100000009? Ciao, Michael. --------------ms040106020009060205040508 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CucwggT9MIID5aADAgECAhBFRleVrRF8X5GwbV0tcLCgMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwOTE2MDcxNjUxWhcNMTkxMjE2MDcxNjUxWjBEMR0wGwYDVQQDDBRtaWNo YWVsQHN0cm9lZGVyLmNvbTEjMCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRlci5jb20w ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQChMBt5jtuLXsNQ5U7rBbZit8sknIwz hfaousT3d/fssQ6qZwe9l1yklILSXVMqI7/bxbiqcd3zrz+imdSlZPrFBHGfh04DZHCfss2F RwSswGejqP1qE3hPvZi96wFfOMqenpN+pSXqNJ1OPBCJ8a+8ZEioFKoEj3HkCCXjbmezAgms FuA7aFE9BfjJ2eQKw8B9G8X1FjvOTinYSZ2F+qHpKgywl4HTx0dMnYy+Pwu4DDIHkEaVH+uj K1/ed76WUEH51mX9m2Xu0onfQlSM3me6EvAAZiIDsCEbF9WttRuJbpfCFo0m2uW7BBugS7EG Jro1nRSQVnpJyTFgHb5EGMVVAgMBAAGjggG4MIIBtDAOBgNVHQ8BAf8EBAMCBLAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYDVR0OBBYEFFh1801TSuxT Nltnv9rOjrZzUUgNMB8GA1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUnSG1oMG8GCCsGAQUF BwEBBGMwYTAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29tMDkGCCsGAQUF BzAChi1odHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5jcnQwOAYD VR0fBDEwLzAtoCugKYYnaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEuY3Js MB8GA1UdEQQYMBaBFG1pY2hhZWxAc3Ryb2VkZXIuY29tMCMGA1UdEgQcMBqGGGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tLzBHBgNVHSAEQDA+MDwGCysGAQQBgbU3AQIFMC0wKwYIKwYBBQUH AgEWH2h0dHBzOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kwDQYJKoZIhvcNAQELBQADggEB AKiJ9wpjJeHdEzHDZyqmhn4cHcRj9Ag7ZQK0meq1N3oQ9M1YeVge6vZe20LXojgXsNUQGLSt 1lW2s7fABkL9CF+/RtWznHxlp4YpWX/RgbHBo3uXKNA5JUOjbxQ2+1b1jaTp/FUrSIISAxgd RpeYAODJ0db1x8Q+l66DtIVjj7ktWISdJWE2Opn4QnaRwdj6n35Rul4S2ikUsmxtGrHLpjRR XJqbsGa0RZdJyUKlZ2ZRAoRz4jKHOogQcig937sR5Ut2pGOhrScEhgARY2c8Gs2olRTL3pue mE4vjY0g1Nwr9RzeFwMuasiFh4yD34i6jIRfoNzuLPgydjsJ0grw0akwggXiMIIDyqADAgEC AhBrp4p9CteI1lEK+Vnk57ThMA0GCSqGSIb3DQEBCwUAMH0xCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAe Fw0xNTEyMTYwMTAwMDVaFw0zMDEyMTYwMTAwMDVaMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhv cml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQC9fdr3w6J9g/Zbgv3bW1+uHht1wLUZr5gkrLtXedg17Ake fMyUGwrQdvwObhajcVmnKVxhrUwkZPXRAwZZosRHfEIi5FH7x6SV/8Sp5lZEuiMnvMFG2MzL A84J6Ws5T4NfXZ0qn4TPgnr3X2vPVS51M7Ua9nIJgn8jvTra4eyyQzxvuA/GZwKg7VQfDCmC S+kICslYYWgXOMt2xlsSslxLce0CGWRsT8EpMyt1iDflSjXZIsE7m1uTyHaKZspMLyIyz6my Su8j8BWWHpChNNeTrFuhVfrOAyDPFJVUvKZCLKBhibTLloyy+LatoWELrjdI4a8StZY8+dIR 9t4APXGzAgMBAAGjggFkMIIBYDAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0lBBYwFAYIKwYBBQUH AwIGCCsGAQUFBwMEMBIGA1UdEwEB/wQIMAYBAf8CAQAwMgYDVR0fBCswKTAnoCWgI4YhaHR0 cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMGYGCCsGAQUFBwEBBFowWDAkBggrBgEF BQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29tMDAGCCsGAQUFBzAChiRodHRwOi8vYWlh LnN0YXJ0c3NsLmNvbS9jZXJ0cy9jYS5jcnQwHQYDVR0OBBYEFCSBbDlhvkkPj7cbRivJKLUn SG1oMB8GA1UdIwQYMBaAFE4L7xqkQFulF2mHMMo0aEPQQa7yMD8GA1UdIAQ4MDYwNAYEVR0g ADAsMCoGCCsGAQUFBwIBFh5odHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kwDQYJKoZI hvcNAQELBQADggIBAIvj94fsAYuErQ8BAluc4SMnIwS9NPBwAm5SH9uh2NCXTq7im61g7F1L IiNI/+wq37fUuaMbz4g7VarKQTgf8ubs0p7NZWcIe7Bvem2AWaXBsxsaRTYw5kG3DN8pd1hS EUuFoTa7DmNeFe8tiK1BrL3rbA/m48jp4AiFXgvxprJrW7izsyetOrRHPbkW4Y07v29MdhaP v3u1JELyszXqOzjIYo4sWlC8iDQXwgSW/ntvWy2n4LuiaozlCfXl149tKeqvwlvrla2Yklue /quWp9j9ou4T/OY0CXMuY+B8wNK0ohd2D4ShgFlMSjzAFRoHGKF81snTr2d1A7Ew02oF6UQy CkC2aNNsK5cWOojBar5c7HplX9aHYUCZouxIeU28SONJAxnATgR4cJ2jrpmYSz/kliUJ46S6 UpVDo/ebn9c6PaM/XtDYCCaM/7XX6wc3s++sbQ7CtCn1Ax7df6ufQbwyO0V+oFa9H0KAsjHM zcwk3EV2B2NLatidKE/m7G+rB9m+FlVgIiSp0mGlg43QO9Kh1+JqvTCIzv2bJJkmPMLQJNuK KwHNL8F4GGp6jbAV+WL+LDeGfVcq8DHS3LrD+xyYEXQBiqZEdiPVOMxLDSUCXsDO0uCWpaNQ 8j6y6S9p0xE/Ga0peVLadVHhqf9nXqKaxnr358VgfrxzUIrvOaOjMYIDzDCCA8gCAQEwgYkw dTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0 Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAx IENsaWVudCBDQQIQRUZXla0RfF+RsG1dLXCwoDANBglghkgBZQMEAgEFAKCCAhMwGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcxMjA4MTA0OTEwWjAvBgkq hkiG9w0BCQQxIgQgiNJK+D2jTREoCmmfpYNwdS6gvB4/epr+uNS/6LBL2IUwbAYJKoZIhvcN AQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBmgYJKwYB BAGCNxAEMYGMMIGJMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkw JwYDVQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3Rh cnRDb20gQ2xhc3MgMSBDbGllbnQgQ0ECEEVGV5WtEXxfkbBtXS1wsKAwgZwGCyqGSIb3DQEJ EAILMYGMoIGJMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYD VQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRD b20gQ2xhc3MgMSBDbGllbnQgQ0ECEEVGV5WtEXxfkbBtXS1wsKAwDQYJKoZIhvcNAQEBBQAE ggEAf0b7Dn2zH+5wTYnI0vba1dKppAhYQm5V9wBXSciP0kZFdUTb2qXhA87B0bP5MxQ/8IM9 dVp6TlI9XXG2Ye8GYF4w5CprBDN4fopmJ6p4QiF4etjXdVR2fu+UMtAeRbg2di/cq334Hquy cpLceAaLBVY6+P1kPI/oA9GWv6m9djxCigpy+jeWRWAuoujSLid0qOD6A+gimNm/CLYfNvu7 A+Aq3QiKBSemoB39/JyFoxjuXknFtruzn2q50O0lcjwClSgjdYKp6uZDPdKuHegp91iuItGu K9mG6vlzw3WM/i0XyXy+FZF/BjXOPny/VnyRIezlWO8m3aFBZ8sSTnUItwAAAAAAAA== --------------ms040106020009060205040508--

1 0

(ITS#8786) Allow OpenLDAP to start as non-root
by akram.benaissi＠gmail.com 08 Dec '17

08 Dec '17

Full_Name: Akram Ben Aissi Version: 1.1.10 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (77.154.204.242) Hi, We want to run OpenLDAP in containers without root privilege, nor root user id. Actually, we start it with user uid=100000009, gid=0 And we do proper chgrp 0 and chmod 0770 on require directories. Because of this: https://github.com/winlibs/openldap/blob/master/servers/slapd/user.c#L158 we have that: Could not set real user id to 100000009 It would be better to check that setuid is required only if asked user is different from actual user. Does it make sense ?

1 0

(ITS#8785) Password quality/Strength check
by kashyap_sunita＠ongc.co.in 08 Dec '17

08 Dec '17

Full_Name: Sunita Kashyap Version: 2.4.40-5 OS: RHEL 6.7 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (59.185.103.72) Hi, We have successfully implemented existing password policy in our DIT but the most required feature of password strength is missing in existing overlay. Can you suggest that how we could implement password quality/strength in this version of openldap. Regards, Sunita Kashyap Manager(Programming) ONGC

1 0

(ITS#8784) SIGBUS in mdb_page_touch
by balaret＠gmail.com 07 Dec '17

07 Dec '17

Full_Name: Sergey Z Version: LMDB_0.9.19 OS: Android URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2620:119:5001:2242:9215:2763:ff1b:ae35) Hey guys, We are using LMDB 0.9.19 in our Android project and sometimes we are getting SIGBUS in mdb_page_touch(). We can't reproduce this issue on our side but we have plenty of crash reports from our users (about 400 daily): SIGBUS libLMDBAndroid.so.mdb_page_touch ( mdb .c :2412) libLMDBAndroid.so.mdb_page_search ( mdb .c :5610) libLMDBAndroid.so.mdb_freelist_save ( mdb .c :3128) libLMDBAndroid.so.mdb_txn_commit ( mdb .c :3606) This is probably a platform specific issue because 95% of crashes happened on Android 7.0. I would greatly appreciate if you help to shed a light on this - any ideas what might goes wrong or what might cause such an issue. Thank you, Sergey

1 0

Re: (ITS#8783) LMDB on network share path is inconsistent after put data
by hyc＠symas.com 06 Dec '17

06 Dec '17

serg.brester(a)sebres.de wrote: > Full_Name: Sergey Brester > Version: all, also latest master 4d5e2d2a2ac38b9d56b6ba73187c325024718167 > OS: windows > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (80.154.98.131) > > > If I save many data into LMDB file placed in network share, only the latest key > is really in the database after reopen. The docs explicitly state not to use LMDB with remote filesystems. http://www.lmdb.tech/doc/ Closing this ITS. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#8783) LMDB on network share path is inconsistent after put data
by serg.brester＠sebres.de 06 Dec '17

06 Dec '17

Full_Name: Sergey Brester Version: all, also latest master 4d5e2d2a2ac38b9d56b6ba73187c325024718167 OS: windows URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (80.154.98.131) If I save many data into LMDB file placed in network share, only the latest key is really in the database after reopen. Tested single threaded (1 process, 1 thread). No matter which flags supplied to mdb_env_open... So repeateable writing of 10 keys (total 960 times) should result in: Target-state: 10 keys { "some-key-0": "951", "some-key-1": "952", "some-key-2": "953", "some-key-3": "954", "some-key-4": "955", "some-key-5": "956", "some-key-6": "957", "some-key-7": "958", "some-key-8": "959", "some-key-9": "960" } After reopen of database you'll see: Actual-state: 1 key { "some-key-9": "960" } Doing the same on local drive works fine and actual state is equal target state.

1 0

Re: (ITS#8782) Memory leak in ldap_cancel
by hyc＠symas.com 04 Dec '17

04 Dec '17

cheimes(a)redhat.com wrote: > Full_Name: Christian Heimes > Version: 2.4.45 > OS: Fedora > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (2001:16b8:6097:b200:c324:8c3d:7869:1a1b) > > > While I was looking for memory leaks in python-ldap, Valgrind detected a memory > leak in ldap_cancel: Thanks for the report. Fixed now in master. > > ==30178== 22 (16 direct, 6 indirect) bytes in 1 blocks are definitely lost in > loss record 27 of 5,810 > ==30178== at 0x4C2FB6B: malloc (vg_replace_malloc.c:299) > ==30178== by 0x14CBD9E4: ber_memalloc_x (memory.c:228) > ==30178== by 0x14CBC940: ber_flatten (io.c:437) > ==30178== by 0x14A81733: ldap_cancel (cancel.c:50) > ==30178== by 0x1485A3BA: l_ldap_cancel (LDAPObject.c:779) > ==30178== by 0x4FC24EF: PyCFunction_Call (in > /usr/lib64/libpython3.6m.so.1.0) > ==30178== by 0x4FF891C: _PyEval_EvalFrameDefault (in > /usr/lib64/libpython3.6m.so.1.0) > ==30178== by 0x4F590B2: ??? (in /usr/lib64/libpython3.6m.so.1.0) > ==30178== by 0x4F8BE10: ??? (in /usr/lib64/libpython3.6m.so.1.0) > ==30178== by 0x4FC933D: ??? (in /usr/lib64/libpython3.6m.so.1.0) > ==30178== by 0x4FF2EC9: _PyEval_EvalFrameDefault (in > /usr/lib64/libpython3.6m.so.1.0) > ==30178== by 0x4F590B2: ??? (in /usr/lib64/libpython3.6m.so.1.0) > > I think the function is missing a call to ber_bvfree(cancelidvalp). > > python-ldap issue: https://github.com/python-ldap/python-ldap/issues/82 > Code: https://github.com/openldap/openldap/blob/master/libraries/libldap/cancel.c… > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#8782) Memory leak in ldap_cancel
by cheimes＠redhat.com 04 Dec '17

04 Dec '17

Full_Name: Christian Heimes Version: 2.4.45 OS: Fedora URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2001:16b8:6097:b200:c324:8c3d:7869:1a1b) While I was looking for memory leaks in python-ldap, Valgrind detected a memory leak in ldap_cancel: ==30178== 22 (16 direct, 6 indirect) bytes in 1 blocks are definitely lost in loss record 27 of 5,810 ==30178== at 0x4C2FB6B: malloc (vg_replace_malloc.c:299) ==30178== by 0x14CBD9E4: ber_memalloc_x (memory.c:228) ==30178== by 0x14CBC940: ber_flatten (io.c:437) ==30178== by 0x14A81733: ldap_cancel (cancel.c:50) ==30178== by 0x1485A3BA: l_ldap_cancel (LDAPObject.c:779) ==30178== by 0x4FC24EF: PyCFunction_Call (in /usr/lib64/libpython3.6m.so.1.0) ==30178== by 0x4FF891C: _PyEval_EvalFrameDefault (in /usr/lib64/libpython3.6m.so.1.0) ==30178== by 0x4F590B2: ??? (in /usr/lib64/libpython3.6m.so.1.0) ==30178== by 0x4F8BE10: ??? (in /usr/lib64/libpython3.6m.so.1.0) ==30178== by 0x4FC933D: ??? (in /usr/lib64/libpython3.6m.so.1.0) ==30178== by 0x4FF2EC9: _PyEval_EvalFrameDefault (in /usr/lib64/libpython3.6m.so.1.0) ==30178== by 0x4F590B2: ??? (in /usr/lib64/libpython3.6m.so.1.0) I think the function is missing a call to ber_bvfree(cancelidvalp). python-ldap issue: https://github.com/python-ldap/python-ldap/issues/82 Code: https://github.com/openldap/openldap/blob/master/libraries/libldap/cancel.c…

1 0

Re: (ITS#8427) Incorrect value of tls_reqcert in syncrepl
by mkp37215＠gmail.com 01 Dec '17

01 Dec '17

I, Maciej Puzio, hereby place the above modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.

1 0

(ITS#8781) "connection_read(248): no connection!" on 2.4.44
by mramitsingh85＠gmail.com 30 Nov '17

30 Nov '17

Full_Name: Amit kumar singh Version: 2.4.44 OS: CentOS release 6.9 (Final) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (14.141.104.38) Issue on replication and get below error. Nov 30 17:03:55 host slapd[709]: connection_read(346): no connection! Nov 30 17:03:55 host slapd[709]: connection_read(346): no connection! Nov 30 17:03:55 host[709]: connection_read(362): no connection! I was searching issue and found that fixed ref: ITS#6548 on 2.4.27. But strange thing is that it comes up again in 2.4.44. Not sure If I am correct but need your help to look into it.

1 0

(ITS#8780) Plug a socket leak in ldap_new_connection made by unsuccessful connection attempts
by hguo＠suse.com 30 Nov '17

30 Nov '17

Full_Name: Houzuo Guo Version: master OS: URL: ftp://ftp.openldap.org/incoming/houzuo-guo-171130.patch Submission from: (NULL) (195.135.221.2) In case that ldap connection is attempted on failed URLs prior to establishing a successful connection, the failed connection sockets are never freed. This patch plugs the socket descriptor leak.

1 0

Re: (ITS#8779) slapo-seqmod missing manpage
by hyc＠symas.com 29 Nov '17

29 Nov '17

quanah(a)openldap.org wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.45 > OS: N/A > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (47.208.148.239) > > > The seqmod overlay is missing a man page. This should be fixed. > Pretty sure we've discussed this many times before. No. The seqmod overlay is not meant to be executed and used by anyone. It is meant to be a model for overlay authors to read and learn from. Close this ITS. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#8779) slapo-seqmod missing manpage
by quanah＠openldap.org 27 Nov '17

27 Nov '17

Full_Name: Quanah Gibson-Mount Version: 2.4.45 OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.148.239) The seqmod overlay is missing a man page. This should be fixed.

1 0

Re: (ITS#8777) [LMDB] Closing read cursor uses already freed transaction (MDB_VL32)
by hyc＠symas.com 27 Nov '17

27 Nov '17

Markus Junginger wrote: > Thanks for the report. Unfortunately your suggested fix means the rpage > test will always be skipped on read-only cursors, which will break the > rpage tracking if the txn is still alive. > > > Could you maybe explain a bit about rpages? Why does mdb_cursor_close need to > unref pages, but not mdb_cursor_renew? If closing a transaction does not clean > up rpages, I would have expected mdb_cursor_renew would have to do. And why > does setting MDB_VL32 affect rpages in the first place? To my understanding, > MDB_VL32 is about using 64 bits also on 32 bit CPUs, so a differences on page > handling seem surprising at first sight. Think about how LMDB works. LMDB was originally written for use on 64bit CPUs, with 64bit virtual address spaces. It expects to map an entire DB into virtual memory using a single mmap call. Obviously this cannot be done when trying to use a DB larger than 2GB on a machine with only a 32bit virtual address space. When using MDB_VL32 to access a 64bit DB on a 32bit CPU, the DB cannot fit into a single mmap. It must be mapped in chunks, and the chunks must be mapped, unmapped, and remapped on demand. The rpages thus need to be tracked, to know which are currently mapped. None of this rpage tracking exists in the native non-VL32 build because it's completely unnecessary. Also note that the MDB_VL32 feature is not officially released. You're free to use it if you want, but there is no expectation that it is suitable for general use. When you use unreleased features, you're expected to know how to support yourself. When you use LMDB at all, you're expected to know how virtual addresses work. Ideally, you should quit using obsolete 32bit CPUs. -- -- 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#8777) [LMDB] Closing read cursor uses already freed transaction (MDB_VL32)
by hyc＠symas.com 27 Nov '17

27 Nov '17

Markus Junginger wrote: > Thanks for your fast response. > >> Thanks for the report. Unfortunately your suggested fix means >> the rpage test will always be skipped on read-only cursors, which >> will break the rpage tracking if the txn is still alive. > > Does that mean it's not trivial to fix and will take some time? Correct. And I'm still on holiday this week, won't be looking deeper into this for a while. > It's a last outstanding issue for a release, so I guess we have to find a > work around until it's properly fixed? Yes. Best is to use mdb_txn_reset/renew instead of txn_abort. -- -- 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#8777) [LMDB] Closing read cursor uses already freed transaction (MDB_VL32)
by markus＠greenrobot.de 26 Nov '17

26 Nov '17

--94eb2c123fa4650778055ee78f61 Content-Type: text/plain; charset="UTF-8" > > Thanks for the report. Unfortunately your suggested fix means the rpage > test will always be skipped on read-only cursors, which will break the > rpage tracking if the txn is still alive. Could you maybe explain a bit about rpages? Why does mdb_cursor_close need to unref pages, but not mdb_cursor_renew? If closing a transaction does not clean up rpages, I would have expected mdb_cursor_renew would have to do. And why does setting MDB_VL32 affect rpages in the first place? To my understanding, MDB_VL32 is about using 64 bits also on 32 bit CPUs, so a differences on page handling seem surprising at first sight. Thanks, Markus --94eb2c123fa4650778055ee78f61 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo= ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left= :1px solid rgb(204,204,204);padding-left:1ex">Thanks for the report. Unfort= unately your suggested fix means the rpage test will always be skipped on r= ead-only cursors, which will break the rpage tracking if the txn is still a= live.</blockquote><div><br></div><div>Could you maybe explain a bit about r= pages? Why does=C2=A0<span style=3D"font-size:12.8px">mdb_cursor_close=C2= =A0</span>need to unref pages, but not mdb_cursor_renew? If closing a trans= action does not clean up rpages, I would have expected mdb_cursor_renew wou= ld have to do. And why does setting MDB_VL32 affect rpages in the first pla= ce? To my understanding, MDB_VL32=C2=A0 is about using 64 bits also on 32 b= it CPUs, so a differences on page handling seem surprising at first sight.<= /div><div><br></div><div>Thanks,</div><div>Markus</div><div><br></div></div= ></div></div> --94eb2c123fa4650778055ee78f61--

1 0

(ITS#8778) Phone numbers "-" and " " fail normalization
by h.b.furuseth＠usit.uio.no 26 Nov '17

26 Nov '17

Full_Name: Hallvard B Furuseth Version: 2.4.45, master OS: Linux x86_64 URL: Submission from: (NULL) (193.90.52.167) Submitted by: hallvard telephoneNumberNormalize() fails for a non-empty value of only spaces+hyphens. The validate function, printableStringValidate(), succeeds. They should agree. I'll make Normalize return one space. That seems the minimal change.

1 0

Re: (ITS#8777) [LMDB] Closing read cursor uses already freed transaction (MDB_VL32)
by markus＠greenrobot.de 26 Nov '17

26 Nov '17

Thanks for your fast response. > Thanks for the report. Unfortunately your suggested fix means > the rpage test will always be skipped on read-only cursors, which > will break the rpage tracking if the txn is still alive. Does that mean it's not trivial to fix and will take some time? It's a last outstanding issue for a release, so I guess we have to find a work around until it's properly fixed? Thanks, Markus

1 0

Re: (ITS#8777) [LMDB] Closing read cursor uses already freed transaction (MDB_VL32)
by hyc＠symas.com 26 Nov '17

26 Nov '17

markus(a)greenrobot.de wrote: > Full_Name: Markus Junginger > Version: mdb.master > OS: Ubuntu > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (77.190.230.93) > > > Read cursors may outlive a transaction to be renewed with another. Thus, cursors > should be correctly closed even after their last transaction was aborted. But > they access the (already freed) transaction during closing when MDB_VL32 is used > (mdb.master branch). > > ASan captures this like this: > ==19722==ERROR: AddressSanitizer: heap-use-after-free on address 0x61100001b140 > at pc 0x000000ea2387 bp 0x7ffd36e3cd20 sp 0x7ffd36e3cd18 > READ of size 8 at 0x61100001b140 thread T0 > #0 0xea2386 in mdb_cursor_unref mdb.c:2082:18 > #1 0xec577b in mdb_cursor_close mdb.c:8538:3 > > 0x61100001b140 is located 128 bytes inside of 250-byte region > [0x61100001b0c0,0x61100001b1ba) > freed by thread T0 here: > #0 0x74f840 in __interceptor_cfree.localalias.0 (...) > #1 0xe8ea98 in mdb_txn_end mdb.c:3380:3 > #2 0xe8ecc5 in mdb_txn_abort mdb.c:3405:2 > > > Possible fix for line mdb.c:2082 (applying what I found in mdb_cursor_close): > - if (mc->mc_txn->mt_rpages[0].mid) { > + if ((mc->mc_flags & C_UNTRACK) && mc->mc_txn->mt_rpages[0].mid) { > > > Code to reproduce using MDB_VL32: > err = mdb_txn_begin(env, nullptr, MDB_RDONLY, &tx); > err = mdb_cursor_open(tx, dbi, &cursor); > // We must have data so get will set C_INITIALIZED > err = mdb_cursor_get(cursor, &key, &value, MDB_SET_KEY); > mdb_txn_abort(tx); > mdb_cursor_close(cursor); // <- still uses tx Thanks for the report. Unfortunately your suggested fix means the rpage test will always be skipped on read-only cursors, which will break the rpage tracking if the txn is still alive. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#8777) [LMDB] Closing read cursor uses already freed transaction (MDB_VL32)
by markus＠greenrobot.de 26 Nov '17

26 Nov '17

Full_Name: Markus Junginger Version: mdb.master OS: Ubuntu URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (77.190.230.93) Read cursors may outlive a transaction to be renewed with another. Thus, cursors should be correctly closed even after their last transaction was aborted. But they access the (already freed) transaction during closing when MDB_VL32 is used (mdb.master branch). ASan captures this like this: ==19722==ERROR: AddressSanitizer: heap-use-after-free on address 0x61100001b140 at pc 0x000000ea2387 bp 0x7ffd36e3cd20 sp 0x7ffd36e3cd18 READ of size 8 at 0x61100001b140 thread T0 #0 0xea2386 in mdb_cursor_unref mdb.c:2082:18 #1 0xec577b in mdb_cursor_close mdb.c:8538:3 0x61100001b140 is located 128 bytes inside of 250-byte region [0x61100001b0c0,0x61100001b1ba) freed by thread T0 here: #0 0x74f840 in __interceptor_cfree.localalias.0 (...) #1 0xe8ea98 in mdb_txn_end mdb.c:3380:3 #2 0xe8ecc5 in mdb_txn_abort mdb.c:3405:2 Possible fix for line mdb.c:2082 (applying what I found in mdb_cursor_close): - if (mc->mc_txn->mt_rpages[0].mid) { + if ((mc->mc_flags & C_UNTRACK) && mc->mc_txn->mt_rpages[0].mid) { Code to reproduce using MDB_VL32: err = mdb_txn_begin(env, nullptr, MDB_RDONLY, &tx); err = mdb_cursor_open(tx, dbi, &cursor); // We must have data so get will set C_INITIALIZED err = mdb_cursor_get(cursor, &key, &value, MDB_SET_KEY); mdb_txn_abort(tx); mdb_cursor_close(cursor); // <- still uses tx

1 0

Re: (ITS#8776) lessOrEqual does not work as expected
by kristianmccolm＠hotmail.com 23 Nov '17

23 Nov '17

--_000_BN6PR04MB08825B65B73F5FF9B6674966DD210BN6PR04MB0882namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello Michael, The lessOrEqual does work as expected now after shutting down the directory= and running slapindex. Thanks Kristian ________________________________ From: Michael Str=F6der <michael(a)stroeder.com> Sent: November 23, 2017 15:19 To: kristianmccolm(a)hotmail.com; openldap-its(a)OpenLDAP.org Subject: Re: (ITS#8776) lessOrEqual does not work as expected kristianmccolm(a)hotmail.com wrote: > Full_Name: Kristian McColm > Version: slapd 2.4.40 Did you also test with a newer release? > With an attribute type defined in the schema and index as per the below, = and the > value of the attribute set to 0, the lessOrEqual filter does not work as > expected. It works for me. Example filter (aeStatus<=3D1) also finds entries with (aeStatus=3D0): https://demo.ae-dir.com/web2ldap?ldapi://%2Fopt%2Fae-dir%2Frun%2Fslapd%2Fld= api/cn=3Dtest,ou=3Dae-dir??sub?(aeStatus<=3D1)?bindname=3Duid%3Dzots%2Ccn%3= Dtest%2Cou%3Dae-dir,X-BINDPW=3DCorrectHorseBatteryStaple (This is an OpenLDAP 2.4.45 server but this worked for me with older releases too.) > Schema attribute: > olcAttributeTypes: {1} ( <oid> NAME 'num' DESC 'Numeric Attribute' SYNTAX > 1.3.6.1.4.1.1466.115.121.1.27 X-ORIGIN 'user defined' EQUALITY integerMat= ch > ORDERING integerOrderingMatch ) Did you use <oid> as a placeholder or is that value really literally in your schema? If you used it as a placeholder herein which OID did you really use? Did you eventually changed index-related schema config without re-indexing? Ciao, Michael. --_000_BN6PR04MB08825B65B73F5FF9B6674966DD210BN6PR04MB0882namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <html> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-= 1"> <style type=3D"text/css" style=3D"display:none;"></style> </head> <body dir=3D"ltr"> <div id=3D"divtagdefaultwrapper" style=3D"font-size:12pt;color:#000000;font= -family:Calibri,Helvetica,sans-serif;" dir=3D"ltr"> <p style=3D"margin-top:0;margin-bottom:0">Hello Michael,</p> <p style=3D"margin-top:0;margin-bottom:0"><br> </p> <p style=3D"margin-top:0;margin-bottom:0">The lessOrEqual does work as expe= cted now after shutting down the directory and running slapindex. <br> </p> <p style=3D"margin-top:0;margin-bottom:0"><br> </p> <p style=3D"margin-top:0;margin-bottom:0">Thanks <br> </p> <p style=3D"margin-top:0;margin-bottom:0">Kristian</p> <br> <br> <div style=3D"color: rgb(0, 0, 0);"> <hr style=3D"display:inline-block;width:98%" tabindex=3D"-1"> <div id=3D"divRplyFwdMsg" dir=3D"ltr"><font style=3D"font-size:11pt" face= =3D"Calibri, sans-serif" color=3D"#000000"><b>From:</b> Michael Str=F6der &= lt;michael(a)stroeder.com><br> <b>Sent:</b> November 23, 2017 15:19<br> <b>To:</b> kristianmccolm(a)hotmail.com; openldap-its(a)OpenLDAP.org<br> <b>Subject:</b> Re: (ITS#8776) lessOrEqual does not work as expected</font> <div> </div> </div> <div class=3D"BodyFragment"><font size=3D"2"><span style=3D"font-size:10pt;= "> <div class=3D"PlainText">kristianmccolm(a)hotmail.com wrote:<br> > Full_Name: Kristian McColm<br> > Version: slapd 2.4.40<br> <br> Did you also test with a newer release?<br> <br> > With an attribute type defined in the schema and index as per the belo= w, and the<br> > value of the attribute set to 0, the lessOrEqual filter does not work = as<br> > expected.<br> <br> It works for me.<br> <br> Example filter (aeStatus<=3D1) also finds entries with (aeStatus=3D0):<b= r> <br> <a href=3D"https://demo.ae-dir.com/web2ldap?ldapi://%2Fopt%2Fae-dir%2Frun%2= Fslapd%2Fldapi/cn=3Dtest,ou=3Dae-dir??sub?(aeStatus<=3D1)?bindname=3Duid= %3Dzots%2Ccn%3Dtest%2Cou%3Dae-dir,X-BINDPW=3DCorrectHorseBatteryStaple">htt= ps://demo.ae-dir.com/web2ldap?ldapi://%2Fopt%2Fae-dir%2Frun%2Fslapd%2Fldapi= /cn=3Dtest,ou=3Dae-dir??sub?(aeStatus<=3D1)?bindname=3Duid%3Dzots%2Ccn%3= Dtest%2Cou%3Dae-dir,X-BINDPW=3DCorrectHorseBatteryStaple</a><br> <br> (This is an OpenLDAP 2.4.45 server but this worked for me with older<br> releases too.)<br> <br> > Schema attribute:<br> > olcAttributeTypes: {1} ( <oid> NAME 'num' DESC 'Numeric Attribut= e' SYNTAX<br> > 1.3.6.1.4.1.1466.115.121.1.27 X-ORIGIN 'user defined' EQUALITY integer= Match<br> > ORDERING integerOrderingMatch )<br> <br> Did you use <oid> as a placeholder or is that value really literally = in<br> your schema? If you used it as a placeholder herein which OID did you<br> really use?<br> <br> Did you eventually changed index-related schema config without re-indexing?= <br> <br> Ciao, Michael.<br> <br> </div> </span></font></div> </div> </div> </body> </html> --_000_BN6PR04MB08825B65B73F5FF9B6674966DD210BN6PR04MB0882namp_--

1 0

Re: (ITS#8776) lessOrEqual does not work as expected
by michael＠stroeder.com 23 Nov '17

23 Nov '17

This is a cryptographically signed message in MIME format. --------------ms080105080402020204000104 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable kristianmccolm(a)hotmail.com wrote: > Full_Name: Kristian McColm > Version: slapd 2.4.40 Did you also test with a newer release? > With an attribute type defined in the schema and index as per the below= , and the > value of the attribute set to 0, the lessOrEqual filter does not work a= s > expected. It works for me. Example filter (aeStatus<=3D1) also finds entries with (aeStatus=3D0): https://demo.ae-dir.com/web2ldap?ldapi://%2Fopt%2Fae-dir%2Frun%2Fslapd%2F= ldapi/cn=3Dtest,ou=3Dae-dir??sub?(aeStatus<=3D1)?bindname=3Duid%3Dzots%2C= cn%3Dtest%2Cou%3Dae-dir,X-BINDPW=3DCorrectHorseBatteryStaple (This is an OpenLDAP 2.4.45 server but this worked for me with older releases too.) > Schema attribute: > olcAttributeTypes: {1} ( <oid> NAME 'num' DESC 'Numeric Attribute' SYNT= AX > 1.3.6.1.4.1.1466.115.121.1.27 X-ORIGIN 'user defined' EQUALITY integerM= atch > ORDERING integerOrderingMatch ) Did you use <oid> as a placeholder or is that value really literally in your schema? If you used it as a placeholder herein which OID did you really use? Did you eventually changed index-related schema config without re-indexin= g? Ciao, Michael. --------------ms080105080402020204000104 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CucwggT9MIID5aADAgECAhBFRleVrRF8X5GwbV0tcLCgMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwOTE2MDcxNjUxWhcNMTkxMjE2MDcxNjUxWjBEMR0wGwYDVQQDDBRtaWNo YWVsQHN0cm9lZGVyLmNvbTEjMCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRlci5jb20w ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQChMBt5jtuLXsNQ5U7rBbZit8sknIwz hfaousT3d/fssQ6qZwe9l1yklILSXVMqI7/bxbiqcd3zrz+imdSlZPrFBHGfh04DZHCfss2F RwSswGejqP1qE3hPvZi96wFfOMqenpN+pSXqNJ1OPBCJ8a+8ZEioFKoEj3HkCCXjbmezAgms FuA7aFE9BfjJ2eQKw8B9G8X1FjvOTinYSZ2F+qHpKgywl4HTx0dMnYy+Pwu4DDIHkEaVH+uj K1/ed76WUEH51mX9m2Xu0onfQlSM3me6EvAAZiIDsCEbF9WttRuJbpfCFo0m2uW7BBugS7EG Jro1nRSQVnpJyTFgHb5EGMVVAgMBAAGjggG4MIIBtDAOBgNVHQ8BAf8EBAMCBLAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYDVR0OBBYEFFh1801TSuxT Nltnv9rOjrZzUUgNMB8GA1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUnSG1oMG8GCCsGAQUF BwEBBGMwYTAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29tMDkGCCsGAQUF BzAChi1odHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5jcnQwOAYD VR0fBDEwLzAtoCugKYYnaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEuY3Js MB8GA1UdEQQYMBaBFG1pY2hhZWxAc3Ryb2VkZXIuY29tMCMGA1UdEgQcMBqGGGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tLzBHBgNVHSAEQDA+MDwGCysGAQQBgbU3AQIFMC0wKwYIKwYBBQUH AgEWH2h0dHBzOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kwDQYJKoZIhvcNAQELBQADggEB AKiJ9wpjJeHdEzHDZyqmhn4cHcRj9Ag7ZQK0meq1N3oQ9M1YeVge6vZe20LXojgXsNUQGLSt 1lW2s7fABkL9CF+/RtWznHxlp4YpWX/RgbHBo3uXKNA5JUOjbxQ2+1b1jaTp/FUrSIISAxgd RpeYAODJ0db1x8Q+l66DtIVjj7ktWISdJWE2Opn4QnaRwdj6n35Rul4S2ikUsmxtGrHLpjRR XJqbsGa0RZdJyUKlZ2ZRAoRz4jKHOogQcig937sR5Ut2pGOhrScEhgARY2c8Gs2olRTL3pue mE4vjY0g1Nwr9RzeFwMuasiFh4yD34i6jIRfoNzuLPgydjsJ0grw0akwggXiMIIDyqADAgEC AhBrp4p9CteI1lEK+Vnk57ThMA0GCSqGSIb3DQEBCwUAMH0xCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAe Fw0xNTEyMTYwMTAwMDVaFw0zMDEyMTYwMTAwMDVaMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhv cml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQC9fdr3w6J9g/Zbgv3bW1+uHht1wLUZr5gkrLtXedg17Ake fMyUGwrQdvwObhajcVmnKVxhrUwkZPXRAwZZosRHfEIi5FH7x6SV/8Sp5lZEuiMnvMFG2MzL A84J6Ws5T4NfXZ0qn4TPgnr3X2vPVS51M7Ua9nIJgn8jvTra4eyyQzxvuA/GZwKg7VQfDCmC S+kICslYYWgXOMt2xlsSslxLce0CGWRsT8EpMyt1iDflSjXZIsE7m1uTyHaKZspMLyIyz6my Su8j8BWWHpChNNeTrFuhVfrOAyDPFJVUvKZCLKBhibTLloyy+LatoWELrjdI4a8StZY8+dIR 9t4APXGzAgMBAAGjggFkMIIBYDAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0lBBYwFAYIKwYBBQUH AwIGCCsGAQUFBwMEMBIGA1UdEwEB/wQIMAYBAf8CAQAwMgYDVR0fBCswKTAnoCWgI4YhaHR0 cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMGYGCCsGAQUFBwEBBFowWDAkBggrBgEF BQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29tMDAGCCsGAQUFBzAChiRodHRwOi8vYWlh LnN0YXJ0c3NsLmNvbS9jZXJ0cy9jYS5jcnQwHQYDVR0OBBYEFCSBbDlhvkkPj7cbRivJKLUn SG1oMB8GA1UdIwQYMBaAFE4L7xqkQFulF2mHMMo0aEPQQa7yMD8GA1UdIAQ4MDYwNAYEVR0g ADAsMCoGCCsGAQUFBwIBFh5odHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kwDQYJKoZI hvcNAQELBQADggIBAIvj94fsAYuErQ8BAluc4SMnIwS9NPBwAm5SH9uh2NCXTq7im61g7F1L IiNI/+wq37fUuaMbz4g7VarKQTgf8ubs0p7NZWcIe7Bvem2AWaXBsxsaRTYw5kG3DN8pd1hS EUuFoTa7DmNeFe8tiK1BrL3rbA/m48jp4AiFXgvxprJrW7izsyetOrRHPbkW4Y07v29MdhaP v3u1JELyszXqOzjIYo4sWlC8iDQXwgSW/ntvWy2n4LuiaozlCfXl149tKeqvwlvrla2Yklue /quWp9j9ou4T/OY0CXMuY+B8wNK0ohd2D4ShgFlMSjzAFRoHGKF81snTr2d1A7Ew02oF6UQy CkC2aNNsK5cWOojBar5c7HplX9aHYUCZouxIeU28SONJAxnATgR4cJ2jrpmYSz/kliUJ46S6 UpVDo/ebn9c6PaM/XtDYCCaM/7XX6wc3s++sbQ7CtCn1Ax7df6ufQbwyO0V+oFa9H0KAsjHM zcwk3EV2B2NLatidKE/m7G+rB9m+FlVgIiSp0mGlg43QO9Kh1+JqvTCIzv2bJJkmPMLQJNuK KwHNL8F4GGp6jbAV+WL+LDeGfVcq8DHS3LrD+xyYEXQBiqZEdiPVOMxLDSUCXsDO0uCWpaNQ 8j6y6S9p0xE/Ga0peVLadVHhqf9nXqKaxnr358VgfrxzUIrvOaOjMYIDzDCCA8gCAQEwgYkw dTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0 Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAx IENsaWVudCBDQQIQRUZXla0RfF+RsG1dLXCwoDANBglghkgBZQMEAgEFAKCCAhMwGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcxMTIzMjAxOTA1WjAvBgkq hkiG9w0BCQQxIgQggLNdtpY0mPV/KXlnxaApGLsiY4jM5Sciqt5v2UgVidMwbAYJKoZIhvcN AQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBmgYJKwYB BAGCNxAEMYGMMIGJMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkw JwYDVQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3Rh cnRDb20gQ2xhc3MgMSBDbGllbnQgQ0ECEEVGV5WtEXxfkbBtXS1wsKAwgZwGCyqGSIb3DQEJ EAILMYGMoIGJMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYD VQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRD b20gQ2xhc3MgMSBDbGllbnQgQ0ECEEVGV5WtEXxfkbBtXS1wsKAwDQYJKoZIhvcNAQEBBQAE ggEAWGyJAmdDrMntsX8zdI09M0xOfYtzmvyfwI2/66v0JXT01gaXeyulOdSGFJNfBsjNYhUn inuoMsqCohSo+nuzctIePo1ejbrGTMTSb4lWgs1ZdEDDO5pP8uOe1c3m3wTCVwaFyaRM5FMn eRtZIwdnHpMr43f99ridT8dEz15Nm/Vko+FS0lpI8xIGsN1ViqEnadK2L2tWjokA9MAbeU/J N1ZiJGRNXCkhAT02I9xgJQ3gTNR5hVyXachauBB3sCaDlWDfOx7k7NyVP1/NTYx9GxuTiR+s fprm+Y8lbNmzzcYLp82wwVRccFrzG9etnGuhNlA3SdxLNkKmdGwraIylJQAAAAAAAA== --------------ms080105080402020204000104--

1 0

(ITS#8776) lessOrEqual does not work as expected
by kristianmccolm＠hotmail.com 23 Nov '17

23 Nov '17

Full_Name: Kristian McColm Version: slapd 2.4.40 OS: RHEL 6.8 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (162.208.80.0) With an attribute type defined in the schema and index as per the below, and the value of the attribute set to 0, the lessOrEqual filter does not work as expected. Schema attribute: olcAttributeTypes: {1} ( <oid> NAME 'num' DESC 'Numeric Attribute' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 X-ORIGIN 'user defined' EQUALITY integerMatch ORDERING integerOrderingMatch ) Index attribute: olcDbIndex: num eq,pres Less or Equal does not work: $ ldapsearch -x -h localhost -p 389 -b "uid=bob,dc=test,dc=com" '(num<=1)' # extended LDIF # # LDAPv3 # base <uid=bob,dc=test,dc=com> with scope subtree # filter: (num<=1) # requesting: ALL # # search result search: 2 result: 0 Success # numResponses: 1 Equality match works however: $ ldapsearch -x -h localhost -p 389 -b "uid=bob,dc=test,dc=com" '(num=0)' # extended LDIF # # LDAPv3 # base <uid=bob,dc=test,dc=com> with scope subtree # filter: (num=0) # requesting: ALL # dn: uid=bob,dc=test,dc=com objectClass: top objectClass: testObjectClass uid: bob num: 0 # numResponses: 2 # numEntries: 1 And with a non-zero value for 'num' lessOrEqual works as expected: $ ldapsearch -x -h localhost -p 389 -b "uid=bob,dc=test,dc=com" '(num<=10)' # extended LDIF # # LDAPv3 # base <uid=bob,dc=test,dc=com> with scope subtree # filter: (num<=10) # requesting: ALL # dn: uid=bob,dc=test,dc=com objectClass: top objectClass: testObjectClass uid: bob num: 1 # numResponses: 2 # numEntries: 1

1 0

(ITS#8775) PASSMOD exop fails with RWM and tight ACLs
by quinot＠adacore.com 22 Nov '17

22 Nov '17

Full_Name: Thomas Quinot Version: slapd 2.X (Nov 22 2017 11:39:03) OS: Linux URL: ftp://ftp.openldap.org/incoming/quinot-171122.diff Submission from: (NULL) (2a02:2ab8:224:1:36e6:d7ff:fe09:66dd) If a tight ACL is globally defined for userPassword: access to attrs=userPassword by dn="cn=Manager,o=Local" write by self write by anonymous auth and there is a virtual naming context implemented using a relay backend with rwm overlay: database @BACKEND@ suffix "dc=example,dc=com" [...] database relay suffix o=OtherExample,c=US relay dc=example,dc=com overlay rwm rwm-suffixmassage "dc=example,dc=com" then an end-user's attempt to update her own password will fail with: err=53 text=unwilling to verify old password because at some point we attempt to apply the above ACL to the original (virtual) DN, but considering the resolved (real) DN for the user: 5a1553ea => acl_mask: access to entry "cn=Ursula Hampster,ou=Alumni Association,ou=People,o=OtherExample,c=US", attr "userPassword" requested 5a1553ea => acl_mask: to value by "cn=ursula hampster,ou=alumni association,ou=people,dc=example,dc=com", (=0)

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs