openldap-bugs

openldap-bugs@openldap.org

1 participants
21001 discussions

Re: (ITS#7336) Ldapmodify crashes slapd when updating olcTLSVerifyClient attribute via TLS authentication
by ondra＠mistotebe.net 22 Jun '18

22 Jun '18

On Sun, Mar 23, 2014 at 09:32:22AM +0000, ck(a)cksoft.de wrote: > Hi, > > I can confirm that openldap-2.4.39 still has in issue with this. > > When connecting via TLS I tried to modify olcTLSVerifyClient from never > to try with following ldif: > > dn: cn=config > changetype: modify > replace: olcTLSVerifyClient > olcTLSVerifyClient: try > > this caused slapd to hang indefinetely. > > I was able to successfully modify above when connecting without TLS. > > I need to complete my current task but will set up a small proof of > concept later on in my lab. Hi Christian, have you been able to set up a test configuration that reproduces it with latest OpenLDAP? A cursory test here doesn't seem to do anything of the sort. Thanks, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

(ITS#8868) Inefficiency when processing certain search filters
by quanah＠openldap.org 21 Jun '18

21 Jun '18

Full_Name: Quanah Gibson-Mount Version: 2.4.46 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.148.239) Certain search filters are not processed efficiently in the back-{bhm}db code base. An example is: "(|(&(subscriberid=1)(objectClass=XYZ))(&(subscriberid=2)(objectClass=XYZ)))" In this situation, the contiguous list of possibilities for the objectClass result gets turned into a range, causing each entry to be examined as a match. This significantly increases CPU load and causes a delay in returning the result. Re-arranging the search in the following manner bypasses this issue: (&(objectClass=XYZ)(|(subscriberid=1)(subscriberid=2)))" General timing with back-mdb: .477 seconds for the expensive search .020 seconds for the optimized search For back-bdb, the timing was: .665 seconds for the expensive search .020 seconds for the optimized search

1 0

Re: (ITS#8867) ldap_sasl_bind_s failed error during replication
by michael＠stroeder.com 21 Jun '18

21 Jun '18

The ITS is for reporting bugs only. Please subscribe to the openldap-technical mailing list and post your usage questions there: https://www.openldap.org/lists/mm/listinfo/openldap-technical Ciao, Michael.

1 0

(ITS#8867) ldap_sasl_bind_s failed error during replication
by appana.anil＠gmail.com 21 Jun '18

21 Jun '18

Full_Name: anil kumar appanna Version: 2.4 OS: RHEL URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (143.112.32.4) I configured multi master replication. The configuration went well without any errors, but the data is not replicated from one server to another one. When i looked at the log file, i am getting the below errors slap_client_connect: URI=ldap://***.com DN="cn=config" ldap_sasl_bind_s failed (-1) do_syncrepl: rid=001 rc -1 retrying slap_client_connect: URI=ldap://***.com DN="cn=ldapadm,dc=****,dc=com" ldap_sasl_bind_s failed (-1) appreciate any quick help. I am very new to openldap.

1 0

Re: (ITS#8842) NULL pointer derefence
by ondra＠mistotebe.net 21 Jun '18

21 Jun '18

On Tue, May 01, 2018 at 08:14:50PM +0000, openldap(a)katzen.cc wrote: > 2 small issues: > I'm keeping it brief, let me know if you need more information. > > A malicious LDAP server or mitm attacker can craft a response that causes the > ldap client to crash. Nothing critical, just a simoke DoS. > [...] > The problem here is that retoid can be NULL after ldap_parse_intermediate() is > called. > > Another NULL pointer dereference caused by a bad response: > [...] > The PoC leads to memcpy being called with a NULL pointer as second argument > (ava->la_value.bv_val) in dn2domain() (libraries/libldap/getdn.c): > > AC_MEMCPY( str, ava->la_value.bv_val, ava->la_value.bv_len + 1); Both are fixed in this branch: https://github.com/mistotebe/openldap/tree/its8842 -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

Re: (ITS#8866) RFE: slapo-constraint to return filter used in diagnostic message
by michael＠stroeder.com 20 Jun '18

20 Jun '18

On 06/20/2018 01:41 PM, Michael Ströder wrote: > Ouch! This was not yet complete. I'll come up with a new revision soon. Please review this patch: https://www.stroeder.com/temp/0001-ITS-8866-slapo-unique-to-return-filter-u… Disclaimer: I'm not a C programmer. Thanks for your patience. Ciao, Michael.

1 0

Re: (ITS#8866) RFE: slapo-constraint to return filter used in diagnostic message
by michael＠stroeder.com 20 Jun '18

20 Jun '18

On 06/20/2018 01:26 PM, michael(a)stroeder.com wrote: > Find the patch against master here: > https://www.stroeder.com/temp/0001-ITS-8866-slapo-unique-to-return-filter-u… Ouch! This was not yet complete. I'll come up with a new revision soon. Ciao, Michael.

1 0

Re: (ITS#8866) RFE: slapo-constraint to return filter used in diagnostic message
by michael＠stroeder.com 20 Jun '18

20 Jun '18

Rationale: This patch is meant to enhance user experience in case a client software is used to maintain data directly via LDAP. This is a real-world issue. Find the patch against master here: https://www.stroeder.com/temp/0001-ITS-8866-slapo-unique-to-return-filter-u… Also cleanly applies to RE24 and therefore could be easily added to upcoming release 2.4.47. ;-)

1 0

(ITS#8866) RFE: slapo-constraint to return filter used in diagnostic message
by michael＠stroeder.com 20 Jun '18

20 Jun '18

Full_Name: Version: OS: URL: Submission from: (NULL) (213.240.182.62) See motivation and disclosure considerations in list archive: https://www.openldap.org/lists/openldap-devel/201711/msg00003.html Patch will follow.

1 0

Re: (ITS#8844) LMDB mdb_env_close is unsafe in forked child
by h.b.furuseth＠usit.uio.no 14 Jun '18

14 Jun '18

On 14/06/2018 21:04, Howard Chu wrote: > Hallvard Breien Furuseth wrote: >> On 14/06/2018 20:34, Howard Chu wrote: >>> If there are any table entries under that PID there's no problem >>> removing them. >> >> The problem is that it's arbitrary. Something is exiting without >> clearing its pid slots, and 0.001% of the time this code will catch it. > > Sure. But I don't think it's worthwhile to make a special case here to > skip this step. To my eyes the getpid() is a special case already, to someone trying to understand the code. Though adding a comment could fix that. See below. >> Better to skip this cleanup, or to always do it - but "always" belongs >> in env_open(). If a new env is seeing its pid in use, then it can >> safely clean it out. Last we talked about that, I liked it and you >> did not:-) > > And I don't see any particular reason to add this step. right >>(...) >> Parent, pid P: >> open env A. >> >> Child, pid Q: >> - open and start using env B with the same path. >> - close env A, while B is still open. >> With the new code, this clears pid Q - i.e. B's pids. >> But lmdb.h already lists that as a "don't do that", >> because it also removes B's lock on the lockfile. >> > Yeah, this is still a "don't do that" though, regardless of this > particular ITS. Right. So in summary, there are two cases when getpid() can be there to clean out, and in neither case does it make sense to clean it out. Other than the sense of avoiding one "if () { init two vars; }". I like that better than a comment about not bothering to, but a comment is OK too.

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs