(ITS#8247) ru_RU.UTF-8 search problem
by oleg.a.smirnov＠gmail.com
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
'%бугров%')
8 years
(ITS#8246) defining multiple frontend DBs should probably not be allowed
by ryan＠openldap.org
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?
8 years
(ITS#8245) slapo-unique constraints bypassed by manageDsaIt, change to relax?
by geert＠hendrickx.be
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.
8 years
(ITS#8244) back-ldap entry_get is wrong
by hyc＠openldap.org
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.
8 years
Re: (ITS#8240) OpenLDAP ber_get_next denial of service vulnerability
by hyc＠symas.com
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/
8 years
Re: (ITS#8240) OpenLDAP ber_get_next denial of service vulnerability
by michael＠stroeder.com
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.
8 years
Re: (ITS#8240) OpenLDAP ber_get_next denial of service vulnerability
by hyc＠symas.com
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/
8 years
Re: (ITS#7964) overlay rwm escape issue with more the 9 rules / rewrite statements
by ryan＠nardis.ca
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
8 years
Re: (ITS#8240) OpenLDAP ber_get_next denial of service vulnerability
by h.b.furuseth＠usit.uio.no
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."
8 years
Re: (ITS#8240) OpenLDAP ber_get_next denial of service vulnerability
by h.b.furuseth＠usit.uio.no
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)".
8 years
