openldap-bugs

openldap-bugs@openldap.org

1 participants
20960 discussions

Re: (ITS#6163) back-sql DoS when searching for empty attr
by masarati＠aero.polimi.it 03 Aug '09

03 Aug '09

The bug is in the fact that (cn=) is an invalid filter, because cn's syntax is directoryString, which does not allow the empty string. As such, the filter evaluates to undefined, and this is not properly handled by back-sql. A fix is in HEAD, please test (you only need to patch back-sql/search.c and the patch should apply to almost any OpenLDAP 2.4 version). p.

1 0

Re: (ITS#6181) slapo-unique: slaptest fails in case unique_uri is prepended the keywords "strict" or "ignore"
by masarati＠aero.polimi.it 03 Aug '09

03 Aug '09

The "strict" and the "ignore" keywords must be part of a single argument. In fact, the unique_uri statement only takes one argument, consisting of the optional "strict" and "ignore" keywords followed by a list of URIs. In order to be recognized as a single argument, the whole thing needs to be included in double quotes, like unique_uri "strict ldap:///dc=example,dc=com?uid?sub?(objectClass=account)" p.

1 0

Re: (ITS#6217) proxycache not returning cached data
by masarati＠aero.polimi.it 03 Aug '09

03 Aug '09

As far as I recall, this is a known issue, although I could not locate early postings discussing this issue. What happens is that proxy cache makes use of the first item in the filter to discriminate between responses. In your filter template, the first item is the objectClass equality, which means that any filter with that objectClass value, regardless of the uid value, is treated as a duplicate of the first one. If you reverse the order of the equality filters you'll get the expected behavior. There should be another open ITS for this issue, but I can't locate it right now. p.

1 0

Re: (ITS#6231) The same problem: sasl realms don't work with digest-md5
by masarati＠aero.polimi.it 03 Aug '09

03 Aug '09

Software usage questions should be directed to the appropriate mailing lists, unless there is clear evidence of a software/documentation bug. This ITS will be closed. p.

1 0

Re: (ITS#6152) proxycache enhancements
by hyc＠symas.com 02 Aug '09

02 Aug '09

masarati(a)aero.polimi.it wrote: > Just in case, before it becomes totally incompatible with HEAD code, I > have a patch I never committed, it's about making pcache admin-friendly if > it makes any sense. > > It adds: > > - a (persistent) counter that reports, for each query, how many times it > evaluated to answerable > > - "proxycache-" prefixed statements are passed to the private database. > This allows to avoid ambiguities when applying general database directives > in slapd.conf. In fact, it is not clear whether they apply to the proxy > database or to the cache database. > > If they make sense, I'd like to commit them before slapo-pcache > enhancement begins. Go ahead! -- -- 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#6239) ldap_pvt_tls_check_hostname() may be vulnerable
by hyc＠symas.com 31 Jul '09

31 Jul '09

hyc(a)OpenLDAP.org wrote: > Full_Name: Howard Chu > Version: any > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (76.91.220.157) > Submitted by: hyc > > > Our chkhost implementation for OpenSSL does a simple strcasecmp on the name > obtained from the certificate CN; if the CN has an embedded NUL it is possible > for this check to be spoofed. This is now fixed in HEAD. > > Our chkhost implementation for GnuTLS is not vulnerable. > > We didn't write a chkhost implementation for MozNSS, we just use the default one > they provide. Inspecting their code shows that their default checker is also > vulnerable. I will be writing a replacement for libldap shortly. All fixed in HEAD/RE24. Surprisingly, the GnuTLS API got this one right. So did OpenSSL (we just botched our use of their APIs). But the MozNSS APIs all discard the length info of the data instead of returning it, so we had to reimplement some of their basic name-handling code in libldap. Probably should have just done all of this using DER and liblber too, like the other cert parsing code. -- -- 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

(ITS#6239) ldap_pvt_tls_check_hostname() may be vulnerable
by hyc＠OpenLDAP.org 30 Jul '09

30 Jul '09

Full_Name: Howard Chu Version: any OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.91.220.157) Submitted by: hyc Our chkhost implementation for OpenSSL does a simple strcasecmp on the name obtained from the certificate CN; if the CN has an embedded NUL it is possible for this check to be spoofed. This is now fixed in HEAD. Our chkhost implementation for GnuTLS is not vulnerable. We didn't write a chkhost implementation for MozNSS, we just use the default one they provide. Inspecting their code shows that their default checker is also vulnerable. I will be writing a replacement for libldap shortly.

1 0

Re: (ITS#6238) contrib: lastbind overlay to record timestamp of last successful bind
by michael＠stroeder.com 30 Jul '09

30 Jul '09

jonathan(a)phillipoux.net wrote: > Full_Name: Jonathan Clarke > Version: RE24 > OS: > URL: ftp://ftp.openldap.org/incoming/jonathan-clarke-lastbind-20090730.tgz > Submission from: (NULL) (82.67.204.30) > > Please find, at the above URL, an overlay, built for OpenLDAP 2.4, that > intercepts successful binds and records the current timestamp in an attribute > named "bindTimestamp" in the bound-to entry. It's original use-case is to detect > unused accounts. Detecting unused accounts can also somewhat achieved by using slapo-accesslog with configuration directive "logops session". Still I see some value for such an simple overlay. > A configuration parameter (olcLastBindPrecision) allows to set a minimum > precision for the timestamp (ie, don't update the timestamp unless it's older > than <n> seconds). This avoids a performance hit from many unnecessary writes in > case there are many binds per minute/hour/day/week/etc. Things to consider: Is this attribute supposed to be replicated? How about adding configuration paramters so you can specify 1. the attribute type used and 2. the datetime format. This could be handy in situations where you want to mimique the behaviour of other LDAP servers. Ciao, Michael.

1 0

(ITS#6238) contrib: lastbind overlay to record timestamp of last successful bind
by jonathan＠phillipoux.net 30 Jul '09

30 Jul '09

Full_Name: Jonathan Clarke Version: RE24 OS: URL: ftp://ftp.openldap.org/incoming/jonathan-clarke-lastbind-20090730.tgz Submission from: (NULL) (82.67.204.30) Hi, Please find, at the above URL, an overlay, built for OpenLDAP 2.4, that intercepts successful binds and records the current timestamp in an attribute named "bindTimestamp" in the bound-to entry. It's original use-case is to detect unused accounts. A configuration parameter (olcLastBindPrecision) allows to set a minimum precision for the timestamp (ie, don't update the timestamp unless it's older than <n> seconds). This avoids a performance hit from many unnecessary writes in case there are many binds per minute/hour/day/week/etc. Of course, the behaviour this overlay implements is not described in any RFC, or other. However, it closely resembles some of the functionality from the password policy overlay, and similar functionality already exists in other LDAP servers. I post it here in the hope that it may serve others, and in case the OpenLDAP wishes to include it in one form or another. I would most appreciate any comments or feedback. Regards, Jonathan PS: please note that the OIDs used are not registered, but used temporarily. I do not currently have access to a registered OID to use.

1 0

Re: (ITS#6234) CONFIGURABLE TCP BUFFERS IN SLAPD FEATURE REQUEST
by masarati＠aero.polimi.it 30 Jul '09

30 Jul '09

evaristojosec(a)yahoo.es wrote: > Full_Name: Evaristo Camarero > Version: 2.4.x > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (194.237.142.20) > > > > Hi, > > Working with slapd under heavy load it could be interesting to have TCP buffers > size configurable at slapd application level instead of getting default OS > values. > > Some fast modifications in daemon.c file to achieve a hardcoded value for the > sender buffer are: > > int buf_size = 1572864; /* 1.5 Mb */ > rc =setsockopt ( s, SOL_SOCKET, SO_SNDBUF, (int*)&buf_size, > sizeof(buf_size)); > if(rc==-1) { > Debug( LDAP_DEBUG_ANY, "slapd(%ld): " > "setsockopt(SO_SNDBUF) failed errno=%d (%s)\n", > (long) l.sl_sd, err, sock_errstr(err) ); > } else { > Debug( LDAP_DEBUG_ANY, "slapd(%ld): setsockopt(SO_SNDBUF) to %d\n", > (long) l.sl_sd, buf_size, 0); > } Since you use Linux, you could try the kernel's tcp autotuning capabilities described in tcp(7) (other informative links are <http://fasterdata.es.net/TCP-tuning/linux.html>, <http://www.kernelfaq.com/2007/11/tcp-auto-tuning.html>). Of course, the possibility to manually enforce the size of the buffer may be useful in some cases, so a specific configuration option may deserve consideration. p.

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