openldap-bugs January 2020

openldap-bugs@openldap.org

15 participants
38 discussions

(ITS#9153) replication.sdf inconsistent whitespace
by ryan＠openldap.org 14 Jan '20

14 Jan '20

Full_Name: Ryan Tandy Version: RE24 OS: URL: https://github.com/openldap/openldap/compare/OPENLDAP_REL_ENG_2_4...rtandy:… Submission from: (NULL) (70.66.128.207) Submitted by: ryan This patch fixes indentation of two 'maxsize' lines in the 'Syncrepl Proxy' example. For RE24 only as master lacks these lines (will fix separately).

1 0

(ITS#9152) Configuring autoca before database exists crashes slapd
by quanah＠openldap.org 13 Jan '20

13 Jan '20

Full_Name: Quanah Gibson-Mount Version: HEAD OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.143.26) If you configure autoca via cn=config when the underlying DB does not yet exist, slapd will crash. i.e., I added this entry to my cn=config db: dn: olcOverlay=autoca,olcDatabase={1}mdb,cn=config changetype: add objectClass: olcOverlayConfig objectClass: olcACAConfig olcOverlay: autoca olcACAlocalDN: cn=anvil4.rb.symas.net,ou=Servers,dc=rb,dc=symas,dc=net while the mdb database was not yet populated.

1 0

Re: (ITS#9126) add: pwdChangedTime leads to seg fault
by michael＠stroeder.com 13 Jan '20

13 Jan '20

This still happens with current RE24 snapshot. Is more information needed to address this?

1 0

Re: (ITS#9151) slapd-sock - stumped
by matthew＠schlutech.com 12 Jan '20

12 Jan '20

I will move this there thank you. It is difficult to know where to go - this seems like a bug as the behavior is pervasive in all my testing. I have now tried multiple OS and multiple versions of OpenLDAP. As for the path differences - that was just me copying/pasting from two separate tests. I assure you the problem persists when the paths are correct. As you pointed out - inconsistent in the information I provided therein - not in actual testing. Thank you. On 1/12/20 3:30 AM, Michael Ströder wrote: > On 1/11/20 9:03 PM, matthew(a)schlutech.com wrote: >> Always results in socket connect failed. >> >> database sock >> socketpath /tmp/example.sock >> [..] >> Always: socket connect(/root/example.sock) failed > /tmp/example.sock != /root/example.sock > > Either something's inconsistent in your config or the information you > provided herein. > > Also this does not seem to be a bug report but the ITS is only for > reporting bugs. Please send usage questions to openldap-technical > mailing list. > > Ciao, Michael. > >

1 0

Re: (ITS#9151) slapd-sock - stumped
by michael＠stroeder.com 12 Jan '20

12 Jan '20

On 1/11/20 9:03 PM, matthew(a)schlutech.com wrote: > Always results in socket connect failed. > > database sock > socketpath /tmp/example.sock > [..] > Always: socket connect(/root/example.sock) failed /tmp/example.sock != /root/example.sock Either something's inconsistent in your config or the information you provided herein. Also this does not seem to be a bug report but the ITS is only for reporting bugs. Please send usage questions to openldap-technical mailing list. Ciao, Michael.

1 0

(ITS#9151) slapd-sock - stumped
by matthew＠schlutech.com 11 Jan '20

11 Jan '20

Full_Name: W. Matthew Schlueter Version: 2.4.45+dfsg-1ubuntu1.4 OS: Ubuntu 18.04.3 LTS URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (172.101.204.19) Always results in socket connect failed. Using the examples from the source tree: modulepath /usr/lib/ldap moduleload back_sock.so include /etc/ldap/schema/core.schema database sock socketpath /tmp/example.sock suffix "dc=test,dc=com" Starting slapd: slapd -4 -f /etc/ldap/slapd.conf -u root -g root -d1 Using the perl script example from the source tree plus tried endless debugging with my own code. File permissions all look correct. Scoured for answers. Stumped. Always: socket connect(/root/example.sock) failed

1 0

Re: (ITS#9150) olcDbNoSync: FALSE has the same effect as olcDbNoSync: TRUE
by hyc＠symas.com 10 Jan '20

10 Jan '20

maxime.besson(a)worteks.com wrote: > Full_Name: Maxime Besson > Version: 2.4.48 > OS: Debian Buster / CentOS7 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (2a01:cb00:802:8400:2cbe:3c60:fca6:e50b) > > > While migrating configuration from slapd.conf to cn=config, I noticed something > pretty strange related to the dbnosync option Thanks for the report, fixed now in git master. > > The result of converting the following config: > > include ./core.schema > pidfile ./slapd.1.pid > argsfile ./slapd.1.args > > > database mdb > suffix "dc=example,dc=com" > rootdn "cn=Manager,dc=example,dc=com" > rootpw secret > directory db.1.a > index objectClass eq > index cn,sn,uid pres,eq,sub > index entryUUID,entryCSN eq > > > Is (only interested in MDB config): > # AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify. > # CRC32 3df9c3d6 > dn: olcDatabase={1}mdb > objectClass: olcDatabaseConfig > objectClass: olcMdbConfig > olcDatabase: {1}mdb > olcSuffix: dc=example,dc=com > olcAddContentAcl: FALSE > olcLastMod: TRUE > olcMaxDerefDepth: 15 > olcReadOnly: FALSE > olcRootDN: cn=Manager,dc=example,dc=com > olcRootPW:: c2VjcmV0 > olcSyncUseSubentry: FALSE > olcMonitoring: TRUE > olcDbDirectory: db.1.a > olcDbNoSync: FALSE > olcDbIndex: objectClass eq > olcDbIndex: entryUUID eq > olcDbIndex: entryCSN eq > olcDbIndex: cn pres,eq,sub > olcDbIndex: uid pres,eq,sub > olcDbIndex: sn pres,eq,sub > olcDbMaxReaders: 0 > olcDbMaxSize: 10485760 > olcDbMode: 0600 > olcDbSearchStack: 16 > olcDbMaxEntrySize: 0 > olcDbRtxnSize: 10000 > > > As you can see, olcDbNoSync has the value FALSE, because there was no "dbnosync" > option in slapd.conf, however, performance testing shows a dramatic increase in > write speed after slapd.d migration. Which seems odd to me. It seems like the > MDB database was not syncing to disk anymore despite olcDbNoSync being FALSE > > Removing olcDbNoSync: FALSE from cn=config did restore previous performance and > syncing behavior > > Looking at servers/slapd/back-mdb/config.c:723 I found this: > > case MDB_DBNOSYNC: > if ( c->value_int ) > mdb->mi_dbenv_flags |= MDB_NOSYNC; > else > mdb->mi_dbenv_flags ^= MDB_NOSYNC; > > > The else case seems wrong, I replaced it with > > case MDB_DBNOSYNC: > if ( c->value_int ) > mdb->mi_dbenv_flags |= MDB_NOSYNC; > else > mdb->mi_dbenv_flags &= ~MDB_NOSYNC; > > And it solves the issue on my system. > > Reproduced on master, and 2.4.48, on Debian > > -- -- 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#9147) syncrepl connexion leak when provider uses an expired certificate
by hyc＠symas.com 10 Jan '20

10 Jan '20

maxime.besson(a)worteks.com wrote: > Full_Name: Maxime Besson > Version: 2.4.48 > OS: Debian Buster / CentOS7 > URL: https://cloud.worteks.com/index.php/s/9CE6ALLaAfrxZW4/download > Submission from: (NULL) (92.184.104.113) Thanks for the report and testcase, fixed now in git master. > > > I have two OpenLDAP (2.4.48, Ubuntu) servers running with syncrepl in > mirrormode. > > One of my server's X509 certificates has recently expired, and I noticed that > while it was expired, the other node's connection count kept climbing until it > a "Max open files" condition. It seems that when a Syncrepl consumer encounters > a certificate error, the outgoing LDAP connection to the provider is never > closed. > > Attached to this bug you will find a test case to reproduce this behavior > > # runs a provider with a bogus certificate > # and a consumer with retry=3+ > sh test.sh > ... > TLS certificate verification: Error, self signed certificate > TLS trace: SSL3 alert write:fatal:unknown CA > TLS trace: SSL_connect:error in error > TLS: can't connect: error:1416F086:SSL > routines:tls_process_server_certificate:certificate verify failed (self signed > certificate). > 5e160966 slap_client_connect: URI=ldaps://127.0.1.1:6636/ > DN="cn=manager,dc=example,dc=com" ldap_sasl_bind_s failed (-1) > 5e160966 do_syncrepl: rid=001 rc -1 retrying > ... > and so on, every 3 seconds > > While the consumer retries, running lsof on its PID will reveal the connection > leak: > > 42u TCP localhost:45964->localhost.lan:6636 (CLOSE_WAIT) > 43u TCP localhost:45966->localhost.lan:6636 (CLOSE_WAIT) > 44u TCP localhost:45968->localhost.lan:6636 (CLOSE_WAIT) > 45u TCP localhost:45970->localhost.lan:6636 (CLOSE_WAIT) > 46u TCP localhost:45972->localhost.lan:6636 (CLOSE_WAIT) > 47u TCP localhost:45974->localhost.lan:6636 (CLOSE_WAIT) > 48u TCP localhost:45976->localhost.lan:6636 (CLOSE_WAIT) > 49u TCP localhost:45978->localhost.lan:6636 (CLOSE_WAIT) > 50u TCP localhost:45980->localhost.lan:6636 (CLOSE_WAIT) > 51u TCP localhost:45982->localhost.lan:6636 (CLOSE_WAIT) > 52u TCP localhost:45984->localhost.lan:6636 (CLOSE_WAIT) > 53u TCP localhost:45986->localhost.lan:6636 (CLOSE_WAIT) > 54u TCP localhost:45988->localhost.lan:6636 (CLOSE_WAIT) > 55u TCP localhost:45990->localhost.lan:6636 (CLOSE_WAIT) > 56u TCP localhost:45992->localhost.lan:6636 (CLOSE_WAIT) > 57u TCP localhost:45994->localhost.lan:6636 (CLOSE_WAIT) > 58u TCP localhost:45996->localhost.lan:6636 (CLOSE_WAIT) > 59u TCP localhost:45998->localhost.lan:6636 (CLOSE_WAIT) > 60u TCP localhost:46000->localhost.lan:6636 (CLOSE_WAIT) > 61u TCP localhost:46002->localhost.lan:6636 (CLOSE_WAIT) > 62u TCP localhost:46004->localhost.lan:6636 (CLOSE_WAIT) > 63u TCP localhost:46006->localhost.lan:6636 (CLOSE_WAIT) > 64u TCP localhost:46008->localhost.lan:6636 (CLOSE_WAIT) > > > Modifying the provider URL in slapd.2.conf with a wrong port causes the > syncrepl > consumer to fail and retry just as much, but without connection piling up in > CLOSE_WAIT state. > > This is not a very critical issue because it only affects servers who are in > already degraded condition (broken replication, invalid certificate on the > provider) but I thought it still was worth reporting. > > I was able to reproduce this issue on the git master branch, on released 2.4.48, > on Centos7 and on Debian Buster. > OpenSSL version on the debian system: 1.1.1d-0+deb10u2 > > -- -- 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#9124) CVE-ID?
by michael＠stroeder.com 10 Jan '20

10 Jan '20

On 1/10/20 2:28 PM, Stephan Zeisberg wrote: > So far I have not requested a CVE-Id for the issue. That's what Howard > wrote in this regard: > >> Usual practice for CVEs is not to make them public until fixes are >> released. In the future, you should tick the Major Security Issue >> button for potential CVEs so they can be handled privately before >> release.> > I am not aware of a release including the bugfix for the issue. If the > release already exists I am happy to request a CVE-Id for it First of all, many thanks for finding and submitting issues like this. Disclaimer: I'm not an official OpenLDAP project member and I'm not an expert for this CVE-ID process. >From my understanding you can request a CVE-ID which is kept confidential until the vendor developed a fix. This is useful to already have a unique reference for all the work done upstream to fix a particular security issue and for applying back-port patches to downstream packages (e.g. in Linux distributions). Furthermore OpenLDAP's ITS allows to mark an issue as security issue which hides it from public access. I read Howard's comment that he meant exactly this. Ciao, Michael.

1 0

Re: (ITS#9124) CVE-ID?
by stephan＠srlabs.de 10 Jan '20

10 Jan '20

--_000_e1c562ac33aa2ed6c8e93818cf4da3fasrlabsde_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTWljaGFlbCDigJQNCg0KU28gZmFyIEkgaGF2ZSBub3QgcmVxdWVzdGVkIGEgQ1ZFLUlkIGZv ciB0aGUgaXNzdWUuIFRoYXQncyB3aGF0IEhvd2FyZCB3cm90ZSBpbiB0aGlzIHJlZ2FyZDoNCg0K VXN1YWwgcHJhY3RpY2UgZm9yIENWRXMgaXMgbm90IHRvIG1ha2UgdGhlbSBwdWJsaWMgdW50aWwg Zml4ZXMgYXJlIHJlbGVhc2VkLiBJbg0KdGhlDQpmdXR1cmUsIHlvdSBzaG91bGQgdGljayB0aGUg TWFqb3IgU2VjdXJpdHkgSXNzdWUgYnV0dG9uIGZvciBwb3RlbnRpYWwgQ1ZFcyBzbw0KdGhleQ0K Y2FuIGJlIGhhbmRsZWQgcHJpdmF0ZWx5IGJlZm9yZSByZWxlYXNlLg0KDQoNCkkgYW0gbm90IGF3 YXJlIG9mIGEgcmVsZWFzZSBpbmNsdWRpbmcgdGhlIGJ1Z2ZpeCBmb3IgdGhlIGlzc3VlLiBJZiB0 aGUgcmVsZWFzZSBhbHJlYWR5IGV4aXN0cyBJIGFtIGhhcHB5IHRvIHJlcXVlc3QgYSBDVkUtSWQg Zm9yIGl0DQoNCkNoZWVycw0KDQogICAgLVN0ZXBoYW4NCg0KT24gMS8xMC8yMCAyOjA0IFBNLCBN aWNoYWVsIFN0csO2ZGVyIHdyb3RlOg0KDQpTdGVwaGFuLA0KDQpyZWdhcmRpbmc6DQoNCmh0dHBz Oi8vd3d3Lm9wZW5sZGFwLm9yZy9pdHMvaW5kZXguY2dpP2ZpbmRpZD05MTI0DQoNCldhcyB0aGVy ZSBldmVyIGEgQ1ZFLUlkIGFzc2lnbmVkIHRvIHRoaXMgaXNzdWU/IEknZCBsaWtlIHRvIHJlZmVy ZW5jZSBpdA0KaW4gYmFjay1wb3J0IHBhdGNoZXMgZm9yIGRvd25zdHJlYW0gcGFja2FnZXMuDQoN CkNpYW8sIE1pY2hhZWwuDQoNCg0K --_000_e1c562ac33aa2ed6c8e93818cf4da3fasrlabsde_ Content-Type: text/html; charset="utf-8" Content-ID: <53AC3735BCF1C94BAC7633E57FADE8D2(a)EURPRD10.PROD.OUTLOOK.COM> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPHA+SGkgTWljaGFl bCDigJQ8L3A+DQo8cD5TbyBmYXIgSSBoYXZlIG5vdCByZXF1ZXN0ZWQgYSBDVkUtSWQgZm9yIHRo ZSBpc3N1ZS4gVGhhdCdzIHdoYXQgSG93YXJkIHdyb3RlIGluIHRoaXMgcmVnYXJkOjxicj4NCjwv cD4NCjxwcmUgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtc3R5bGU6IG5vcm1hbDsg Zm9udC12YXJpYW50LWxpZ2F0dXJlczogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFs OyBmb250LXdlaWdodDogNDAwOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiAyOyB0 ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7 IHdpZG93czogMjsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6 IDBweDsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyB0ZXh0LWRlY29yYXRp b24tc3R5bGU6IGluaXRpYWw7IHRleHQtZGVjb3JhdGlvbi1jb2xvcjogaW5pdGlhbDsiPjxibG9j a3F1b3RlIHR5cGU9ImNpdGUiPjxwcmUgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQt c3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWxpZ2F0dXJlczogbm9ybWFsOyBmb250LXZhcmlh bnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogNDAwOyBsZXR0ZXItc3BhY2luZzogbm9ybWFs OyBvcnBoYW5zOiAyOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10 cmFuc2Zvcm06IG5vbmU7IHdpZG93czogMjsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4 dC1zdHJva2Utd2lkdGg6IDBweDsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUp OyB0ZXh0LWRlY29yYXRpb24tc3R5bGU6IGluaXRpYWw7IHRleHQtZGVjb3JhdGlvbi1jb2xvcjog aW5pdGlhbDsiPlVzdWFsIHByYWN0aWNlIGZvciBDVkVzIGlzIG5vdCB0byBtYWtlIHRoZW0gcHVi bGljIHVudGlsIGZpeGVzIGFyZSByZWxlYXNlZC4gSW4NCnRoZQ0KZnV0dXJlLCB5b3Ugc2hvdWxk IHRpY2sgdGhlIE1ham9yIFNlY3VyaXR5IElzc3VlIGJ1dHRvbiBmb3IgcG90ZW50aWFsIENWRXMg c28NCnRoZXkNCmNhbiBiZSBoYW5kbGVkIHByaXZhdGVseSBiZWZvcmUgcmVsZWFzZS4NCjwvcHJl PjwvYmxvY2txdW90ZT48L3ByZT4NCjxkaXYgY2xhc3M9Im1vei1jaXRlLXByZWZpeCI+SSBhbSBu b3QgYXdhcmUgb2YgYSByZWxlYXNlIGluY2x1ZGluZyB0aGUgYnVnZml4IGZvciB0aGUgaXNzdWUu IElmIHRoZSByZWxlYXNlIGFscmVhZHkgZXhpc3RzIEkgYW0gaGFwcHkgdG8gcmVxdWVzdCBhIENW RS1JZCBmb3IgaXQ8L2Rpdj4NCjxkaXYgY2xhc3M9Im1vei1jaXRlLXByZWZpeCI+PGJyPg0KPC9k aXY+DQo8ZGl2IGNsYXNzPSJtb3otY2l0ZS1wcmVmaXgiPkNoZWVyczwvZGl2Pg0KPGRpdiBjbGFz cz0ibW96LWNpdGUtcHJlZml4Ij48YnI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9Im1vei1jaXRlLXBy ZWZpeCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IC1TdGVwaGFuPGJyPg0KPC9kaXY+DQo8ZGl2IGNsYXNz PSJtb3otY2l0ZS1wcmVmaXgiPjxicj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0ibW96LWNpdGUtcHJl Zml4Ij5PbiAxLzEwLzIwIDI6MDQgUE0sIE1pY2hhZWwgU3Ryw7ZkZXIgd3JvdGU6PGJyPg0KPC9k aXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjaXRlPSJtaWQ6MDA5YTgyNTgtZTgxNC1iYTI0 LTliYTktN2UyNDg0OTk3ZTRkQHN0cm9lZGVyLmNvbSI+DQo8cHJlIGNsYXNzPSJtb3otcXVvdGUt cHJlIiB3cmFwPSIiPlN0ZXBoYW4sDQoNCnJlZ2FyZGluZzoNCg0KPGEgY2xhc3M9Im1vei10eHQt bGluay1mcmVldGV4dCIgaHJlZj0iaHR0cHM6Ly93d3cub3BlbmxkYXAub3JnL2l0cy9pbmRleC5j Z2k/ZmluZGlkPTkxMjQiPmh0dHBzOi8vd3d3Lm9wZW5sZGFwLm9yZy9pdHMvaW5kZXguY2dpP2Zp bmRpZD05MTI0PC9hPg0KDQpXYXMgdGhlcmUgZXZlciBhIENWRS1JZCBhc3NpZ25lZCB0byB0aGlz IGlzc3VlPyBJJ2QgbGlrZSB0byByZWZlcmVuY2UgaXQNCmluIGJhY2stcG9ydCBwYXRjaGVzIGZv ciBkb3duc3RyZWFtIHBhY2thZ2VzLg0KDQpDaWFvLCBNaWNoYWVsLg0KDQo8L3ByZT4NCjwvYmxv Y2txdW90ZT4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_e1c562ac33aa2ed6c8e93818cf4da3fasrlabsde_--

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs January 2020