openldap-bugs

openldap-bugs@openldap.org

1 participants
20963 discussions

(ITS#8250) Allowing transaction to be created in the reset state
by rouzier＠gmail.com 19 Sep '15

19 Sep '15

Full_Name: James Rouzier Version: OS: URL: https://github.com/rouzier/openldap/commit/54f60e7eb699778197fa154953fccfa8… Submission from: (NULL) (70.81.32.80) This patch allows mdb_txn_begin to create a transaction in the reset state. So instead of doing this. mdb_txn_begin(env, NULL, MDB_READONLY,&txn); mdb_txn_reset(txn); You now can just do this. mdb_txn_begin(env, NULL, MDB_READONLY| MDB_TXNRESET,&txn); You can view the patch here https://github.com/rouzier/openldap/commit/54f60e7eb699778197fa154953fccfa8… The attached patch file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by James Rouzier <rouzier(a)gmail.com>. I have not assigned rights and/or interest in this work to any party.

1 0

(ITS#8249) add search response to back-null
by hyc＠openldap.org 17 Sep '15

17 Sep '15

Full_Name: Howard Chu Version: 2.4 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (92.251.255.12) Submitted by: hyc Sometimes we need a simple backend like back-null, but which returns at least 1 entry on search requests.

1 0

(ITS#8248) misleading information in manpage about the use of the logfile option
by steffen.hofmann-credner＠bsi.bund.de 17 Sep '15

17 Sep '15

Full_Name: Steffen Hofmann Version: 2.4.42 OS: linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2a01:198:5a1:200:10ea:bdac:f2f:c3b8) Misleading information in slapd.conf: an option _logfile_ is described in slapd.conf: "Specify a file for recording debug log messages. [...]" unfortunately it is not clear, what are "debug log messages". Obviously it is not " debugging statements and operation statistics" which can be controlled by the loglevel option. To be honest, I have no clue what the option is for. The only result I got in using this, what a new, empty log file. My, and (by google a few other, too) expected that the logfile option specify the file for the debugging statements.

1 0

(ITS#8247) ru_RU.UTF-8 search problem
by oleg.a.smirnov＠gmail.com 16 Sep '15

16 Sep '15

Full_Name: Oleg Smirnov Version: 2.4.42 OS: linux ubuntu URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (37.147.131.107) When searching for Russian words confused Tupper And tolower functions: See to end of the select, russian word wrote in low case: "upper(...) like '%low case%'" 55f9ebc5 Constructed query: SELECT DISTINCT ldap_entries.id,ldapx_persons.id,text('inetOrgPerson') AS objectClass,ldap_entries.dn AS dn FROM ldap_entries,ldapx_persons WHERE ldapx_persons.id=ldap_entries.keyval AND ldap_entries.oc_map_id=? AND upper(ldap_entries.dn) LIKE upper('%'||?) AND ldapx_persons.lang=0 AND (upper(ldapx_persons.surname) LIKE '%бугров%')

1 0

(ITS#8246) defining multiple frontend DBs should probably not be allowed
by ryan＠openldap.org 16 Sep '15

16 Sep '15

Full_Name: Ryan Tandy Version: 2.4, master OS: Debian URL: Submission from: (NULL) (24.68.37.4) Submitted by: ryan In #openldap, IsoLinCHiP noted that the following config works as intended, and asked whether it's supported: dn: olcDatabase={-1}frontend,cn=config objectClass: olcDatabaseConfig objectClass: olcFrontendConfig olcDatabase: {-1}frontend olcAccess: {0}to * by dn.base="cn=admin,cn=config" manage by * +0 break dn: olcDatabase={0}config,cn=config objectClass: olcDatabaseConfig olcDatabase: {0}config olcRootDN: cn=admin,cn=config dn: olcDatabase={1}frontend,cn=config objectClass: olcDatabaseConfig%obobjectClass: olcFrontendConfig olcDatabase: {1}frontend olcAccess: {0}to dn.base="" by * read olcAccess: {1}to dn.base="cn=subschema" by * read olcAccess: {2}to dn.subtree="dc=de" attrs=userPassword,userPKCS12 by * auth dn: olcDatabase={2}mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: {2}mdb olcDbDirectory: /usr/local/openldap/var/openldap-data olcRootDN: cn=admin,cn=config olcSuffix: dc=de The current behaviour is that the additional ACLs on olcDatabase={1}frontend get appended to the frontendDB ACL just as if they'd been defined on olcDatabase={-1}frontend. Behaviour for other attributes varies: some are merged with earlier values, or overwrite them; others are rejected. It seems to me that defining a second frontend is neither supported, nor to be depended upon, and therefore should probably be explicitly disallowed. Am I right?

1 0

(ITS#8245) slapo-unique constraints bypassed by manageDsaIt, change to relax?
by geert＠hendrickx.be 14 Sep '15

14 Sep '15

Full_Name: Geert Hendrickx Version: 2.4.42 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.123.14.2) Currently the ManageDsaIt control allows bypassing attribute uniqueness constraints as implemented by slapo-unique(5). This seems inappropriate as the ManageDsaIt control (RFC 3296) is intended for managing referral objects. Also it is set by default by certain clients (specifically Java JNDI) which makes uniqueness constraints practically useless with such clients. The newer Relax Rules control (draft-zeilenga-ldap-relax) seems much more appropriate for this use case, please consider using it instead. The simple pchch below works for me, but I haven't tested its interaction with replication. Geert --- servers/slapd/overlays/unique.c 2015-08-14 17:25:28.000000000 +0200 +++ servers/slapd/overlays/unique.c 2015-09-07 22:00:44.217833199 +0200 @@ -1038,9 +1038,8 @@ Debug(LDAP_DEBUG_TRACE, "==> unique_add <%s>\n", op->o_req_dn.bv_val, 0, 0); - /* skip the checks if the operation has manageDsaIt control in it - * (for replication) */ - if ( op->o_managedsait > SLAP_CONTROL_IGNORED + /* skip the checks if the operation has relax control in it */ + if ( op->o_relax > SLAP_CONTROL_IGNORED && access_allowed ( op, op->ora_e, slap_schema.si_ad_entry, NULL, ACL_MANAGE, NULL ) ) { @@ -1170,9 +1169,8 @@ Debug(LDAP_DEBUG_TRACE, "==> unique_modify <%s>\n", op->o_req_dn.bv_val, 0, 0); - /* skip the checks if the operation has manageDsaIt control in it - * (for replication) */ - if ( op->o_managedsait > SLAP_CONTROL_IGNORED + /* skip the checks if the operation has relax control in it */ + if ( op->o_relax > SLAP_CONTROL_IGNORED && overlay_entry_get_ov(op, &op->o_req_ndn, NULL, NULL, 0, &e, on) == LDAP_SUCCESS && e && access_allowed ( op, e, @@ -1301,9 +1299,8 @@ Debug(LDAP_DEBUG_TRACE, "==> unique_modrdn <%s> <%s>\2222, op->o_req_dn.bv_val, op->orr_newrdn.bv_val, 0); - /* skip the checks if the operation has manageDsaIt control in it - * (for replication) */ - if ( op->o_managedsait > SLAP_CONTROL_IGNORED + /* skip the checks if the operation has relax control in it */ + if ( op->o_relax > SLAP_CONTROL_IGNORED && overlay_entry_get_ov(op, &op->o_req_ndn, NULL, NULL, 0, &e, on) == LDAP_SUCCESS && e && access_allowed ( op, e, --- doc/man/man5/slapo-unique.5 2015-08-14 17:25:28.000000000 +0200 +++ doc/man/man5/slapo-unique.5 2015-09-14 09:22:26.242624918 +0200 @@ -162,7 +162,7 @@ maximum flexibility in meeting site-specific requirements. .LP Replication and operations with -.B manageDsaIt +.B relax control are allowed to bypass this enforcement. It is therefore important that all servers accepting writes have this overlay configured in order to maintain uniqueness in a replicated DIT.

1 0

(ITS#8244) back-ldap entry_get is wrong
by hyc＠openldap.org 13 Sep '15

13 Sep '15

Full_Name: Howard Chu Version: 2.4 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (78.155.236.74) Submitted by: hyc The be_entry_get() entry point is only used for internal operations, not client-initiated operations. Currently it propagates client-provided controls through, but they don't belong there. If be_entry_get is invoked due to an ACL evaluation, and the original client operation was a syncrepl search, and the remote server honors the syncrepl control, then this query may hang because ldap_back_entry_get() doesn't expect to handle any Intermediate responses. Worse, if the control requested RefreshAndPersist, then additional responses may pile up on the session as the remote server sends persist updates.

1 0

Re: (ITS#8240) OpenLDAP ber_get_next denial of service vulnerability
by hyc＠symas.com 12 Sep '15

12 Sep '15

Michael Ströder wrote: > hyc(a)symas.com wrote: >> h.b.furuseth(a)usit.uio.no wrote: >>> On 12/09/15 16:24, michael(a)stroeder.com wrote: >>>> I've compiled with CFLAGS="-DNDEBUG" (also tried CPPFLAGS) but this did not >>>> help. slapd still crashes when hitting the assert. >>> >>> Yes, portable.h #undefs it by default. OpenLDAP has always conflated >>> logging, debug output and asserts behind LDAP_DEBUG. We've been saying >>> for some time that we really ought to do something about that someday... >> >> Yes, and that's more obviously a bug that we can fix. > > Is it an easy fix? Not for 2.4. > I think that in opposite to the OpenLDAP project most people out there > consider this to be a really serious bug to be fixed really soon. > For now with my own builds I apply the patch removing the assert statement. > But I wonder how many asserts statements are in the code which can be hit by > invalid input leading to a crash. Given the lack of OpenLDAP documentation about NDEBUG I have re-reverted my previous revert. The patch has been reinstated. >> Every use of assert is "assert(the code is correct)" - but that often depends >> on dynamic state, not just the statically written code. > > Yes, dynamic state including invalid input. But IMO "assert(the code is > correct)" should never be hit no matter how bad the input was. And it should > definitely not crash the server (with system's ressource limits being a > unavoidable exception). Rephrasing: The meaning of the statement "the code is > correct" should also include "invalid input is properly handled as error" - no > matter what. In this particular case the code already handles the error perfectly well without the assert, so the assert doesn't serve any useful purpose. -- -- 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#8240) OpenLDAP ber_get_next denial of service vulnerability
by michael＠stroeder.com 12 Sep '15

12 Sep '15

hyc(a)symas.com wrote: > h.b.furuseth(a)usit.uio.no wrote: >> On 12/09/15 16:24, michael(a)stroeder.com wrote: >>> I've compiled with CFLAGS="-DNDEBUG" (also tried CPPFLAGS) but this did not >>> help. slapd still crashes when hitting the assert. >> >> Yes, portable.h #undefs it by default. OpenLDAP has always conflated >> logging, debug output and asserts behind LDAP_DEBUG. We've been saying >> for some time that we really ought to do something about that someday... > > Yes, and that's more obviously a bug that we can fix. Is it an easy fix? I think that in opposite to the OpenLDAP project most people out there consider this to be a really serious bug to be fixed really soon. For now with my own builds I apply the patch removing the assert statement. But I wonder how many asserts statements are in the code which can be hit by invalid input leading to a crash. >> Even ignoring that, demanding -NDEBUG is backwards in so many ways: >> >> Using C's features like <assert.h> is not the user's job, it's >> OpenLDAP's (i.e. configure and portable.hin). The person building >> OpenLDAP might not even be a C programmer who knows about the C >> language quirk that it has a feature makes errors crash by default. > > It is standard practice in C code. assert() and NDEBUG are part of the C > standard. A person who doesn't know C has no business building the code. > Certainly the libraries are of no use to them if they're not C programmers > already. This is a black-and-white-only statement which does not meet 90% of the cases out there. >> A simple "./configure --prefix=/whatever" ought to be a reasonable way >> to build OpenLDAP, like with most other packages. There are >> installation instructions and they do not mention NDEBUG. I strongly concur with Hallvard here. > Every use of assert is "assert(the code is correct)" - but that often depends > on dynamic state, not just the statically written code. Yes, dynamic state including invalid input. But IMO "assert(the code is correct)" should never be hit no matter how bad the input was. And it should definitely not crash the server (with system's ressource limits being a unavoidable exception). Rephrasing: The meaning of the statement "the code is correct" should also include "invalid input is properly handled as error" - no matter what. Ciao, Michael.

1 0

Re: (ITS#8240) OpenLDAP ber_get_next denial of service vulnerability
by hyc＠symas.com 12 Sep '15

12 Sep '15

h.b.furuseth(a)usit.uio.no wrote: > On 12/09/15 16:24, michael(a)stroeder.com wrote: >> I've compiled with CFLAGS="-DNDEBUG" (also tried CPPFLAGS) but this did not >> help. slapd still crashes when hitting the assert. > > Yes, portable.h #undefs it by default. OpenLDAP has always conflated > logging, debug output and asserts behind LDAP_DEBUG. We've been saying > for some time that we really ought to do something about that someday... Yes, and that's more obviously a bug that we can fix. > Even ignoring that, demanding -NDEBUG is backwards in so many ways: > > Using C's features like <assert.h> is not the user's job, it's > OpenLDAP's (i.e. configure and portable.hin). The person building > OpenLDAP might not even be a C programmer who knows about the C > language quirk that it has a feature makes errors crash by default. It is standard practice in C code. assert() and NDEBUG are part of the C standard. A person who doesn't know C has no business building the code. Certainly the libraries are of no use to them if they're not C programmers already. > A simple "./configure --prefix=/whatever" ought to be a reasonable way > to build OpenLDAP, like with most other packages. There are > installation instructions and they do not mention NDEBUG. > > In particular since this isn't even about catching a bug in OpenLDAP, > but in the input. If someone wants to crash-debug the input to slapd, > let him #define something when building slapd. You could replace the > assert() with debug_assert() or something. The same goes for any > other assert which doesn't mean "assert(the code is correct)". Every use of assert is "assert(the code is correct)" - but that often depends on dynamic state, not just the statically written code. Just like "assert(SOCKBUF_VALID(sb))" or whatever else. That is the case for the assert in question here. -- -- 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

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