openldap-bugs September 2015

openldap-bugs@openldap.org

25 participants
81 discussions

(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

Re: (ITS#7964) overlay rwm escape issue with more the 9 rules / rewrite statements
by ryan＠nardis.ca 12 Sep '15

12 Sep '15

Hi Michael, On Sat, Sep 12, 2015 at 02:38:44PM +0200, Michael Str=F6der wrote: >I wonder whether that caused a regression parsing multi-line DESC '..' in >schema descriptions. > >Up to now I could load this but it does not work with current RE24 branch: > >objectClass ( 1.3.6.1.4.1.412.100.2.1.3.2 NAME 'dlm1ManagedSystemElement' > DESC 'ManagedSystemElement is the base class for the > System Element hierarchy. Membership Criteria: Any > distinguishable component of a System is a candidate > for inclusion in this class. Examples: software > components, such as files; and devices, such as disk > drives and controllers, and physical components such > as chips and cards.' > SUP dlm1ManagedElement ABSTRACT > MAY ( dlmInstallDate $ dlmName $ dlmStatus ) ) > >This is not schema generated by me. A schema with the above DESC (including line breaks), and SUP top=20 ABSTRACT MAY description, is working fine for me on RE24 (as of c5b4cd6)=20 configured with "--disable-bdb --disable-hdb --enable-rwm". I tested embedding it directly in slapd.conf, including via 'include=20 test.schema', and ldapadd'ing an LDIF version into cn=3Dconfig at runtime. = =20 (admittedly the last is probably not relevant, since it becomes one long=20 logical LDIF line.) Can you provide some more details about the failure you see? Glancing at the RE24 log, I'd look at ITS#8233 as the change most likely=20 to be related, but can't say anything for sure without a reproducible=20 test case. thanks, Ryan

1 0

Re: (ITS#8240) OpenLDAP ber_get_next denial of service vulnerability
by h.b.furuseth＠usit.uio.no 12 Sep '15

12 Sep '15

I wrote: > 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)". Look at LDAP_MEMORY_DEBUG and its doc in liblber/memory.c, for example. With the note "* ... If LDAP_MEMORY_DEBUG & 2 is true, * that includes asserts known to break both slapd and current clients."

1 0

Re: (ITS#8240) OpenLDAP ber_get_next denial of service vulnerability
by h.b.furuseth＠usit.uio.no 12 Sep '15

12 Sep '15

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... 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. 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)".

1 0

← Newer
1
2
3
4
5
6
7
8
9
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs September 2015