openldap-devel

openldap-devel@openldap.org

1416 discussions

RE24 (2.4.26) final testing call
by Quanah Gibson-Mount 29 Jun '11

29 Jun '11

2.4.26 has been tagged (OPENLDAP_REL_ENG_2_4_26). There were a few minor commits since the last testing call. Please test and report back any problems. If nothing is found in the next 24 hours, we will release as-is. Thanks! --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

4 3

ldap_bind_st() call
by Thomas Egerer 27 Jun '11

27 Jun '11

Hello *, I am currently dealing with a problem in a third-party application using openldap to retrieve CRLs. We are evaluating this piece of software for possible vulnerabilities. One of the risk arises from a possible DoS-attack involving the aforementioned CRL-retrieval. Our scenario involves an attacker being able to hijack the LDAP- server delivering the CRLs and replacing the actual LDAP-application by a hand-crafted one which accepts connection attempts on port 389 and then does nothing. As a result the application being evaluated is rendered unusable stalling forever while trying to download the CRL. The reason for this behavior is the function call ldap_simple_bind_s() being used to connect to the server. While we are able to control the actual tcp connect and the retrieval of the CRL using LDAP_OPT_NETWORK_TIMEOUT and LDAP_OPT_TIMEOUT, there seems no option to use something like a ldap_bind_st()- function. A mailinglist-entry back from 2002 suggested the implementation of a custom ldap_bind_st()-function, which I did using ldap_bind() and ldap_result(). Yet, me efforts were in vain as I could not retrieve the ld_error-member from LDAP-structure since it's an opaque struct. I finally ended up with a custom function which essentially does what I want, but I cannot figure out if it's due to a bind-timeout or some other reason since ldap_result() returns -1 on failure and 0 otherwise, not the actual error code. Bottom line is, I'm back where I started: wondering why there is no such a function in openldap *and* if is there any chance getting the one that I wrote -- it's added below -- upstream. I know that ldap_bind_s is deprecated in favour of ldap_sasl_bind_s which I could also extend by a ldap_sasl_bind_st function, but I do not want to put any more effort in something being deemed to fail from the start. To sum it up: any chance to get this upstream? Cheers Thomas diff --git a/include/ldap.h b/include/ldap.h index 3f0c1c4..dc3a48c 100644 --- a/include/ldap.h +++ b/include/ldap.h @@ -1270,6 +1270,15 @@ ldap_bind_s LDAP_P(( /* deprecated, use ldap_sasl_bind_s */ LDAP_CONST char *cred, int authmethod )); +LDAP_F( int ) +ldap_bind_st LDAP_P(( + LDAP *ld, + LDAP_CONST char *who, + LDAP_CONST char *cred, + int authmethod, + struct timeval *timeout, + LDAPMessage **result )); + /* * in sbind.c: */ diff --git a/libraries/libldap/bind.c b/libraries/libldap/bind.c index 875bd69..303ead1 100644 --- a/libraries/libldap/bind.c +++ b/libraries/libldap/bind.c @@ -125,3 +125,32 @@ ldap_bind_s( return( ld->ld_errno = LDAP_AUTH_UNKNOWN ); } } + +int ldap_bind_st( + LDAP *ld, + LDAP_CONST char *dn, + LDAP_CONST char *passwd, + int authmethod, + struct timeval *timeout, + LDAPMessage **res ) +{ + int msgid; + + *res = NULL; + + Debug( LDAP_DEBUG_TRACE, "ldap_bind_st\n", 0, 0, 0 ); + + if ( (msgid = ldap_bind( ld, dn, passwd, authmethod )) == -1 ) + return( ld->ld_errno ); + + if ( ldap_result( ld, msgid, LDAP_MSG_ALL, timeout, res ) == -1 || !*res ) + return( ld->ld_errno ); + + if ( ld->ld_errno == LDAP_TIMEOUT ) { + (void) ldap_abandon( ld, msgid ); + ld->ld_errno = LDAP_TIMEOUT; + return( ld->ld_errno ); + } + + return( ldap_result2error( ld, *res, 0 ) ); +}

2 6

RE24 testing call #3 (2.4.26)
by Quanah Gibson-Mount 27 Jun '11

27 Jun '11

Please test RE24, it has a few new updates. This is a release candidate. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

5 8

RE24 testing call #2 (2.4.26)
by Quanah Gibson-Mount 24 Jun '11

24 Jun '11

Please test RE24. Thanks! --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

4 8

mmap'd DB
by Howard Chu 22 Jun '11

22 Jun '11

The main goal of mdb is to eliminate extra copies of data in various caches. A secondary goal is simplifying config (by eliminating extra caches, there's nothing left to tune/configure). One of the key requirements for this to work is to make the on-disk Entry format identical to the in-memory format. Since the in-memory format is based on pointers, we seem to need a way to nail down the memory map to a fixed address that is constant from run to run. (Just re-capping...) The tricky part is that Entries contain AttributeDescriptions and these obviously depend on whatever schema is loaded on a particular run. If you take no special steps, then adding or deleting schema elements from run to run will invalidate their addresses, and make the on-disk pointers useless. I had a notion to replace AttributeDescription pointers with indices into an array. The array would be persisted into a file, and would only ever grow; items would never be deleted from it. Then Entries could reference the array indices instead of the pointers. A scheme like this could work, but the sheer volume of code that directly (de-)references AD pointers is pretty huge. Not sure if it's the right path to take. Another option was to setup a dedicated ad_alloc() function that carves up its own mmap'd file. Then AD pointers will always be constant from run to run. The trouble here is how to configure the path to this file; all of the hard-coded schema is generated before we ever get to reading the config. A possible approach is to first allocate the AD pointers in an anonymous mmap'd region, then once the config file is read we can open the configured file and pull from there. For this to work we have to reserve a fixed size chunk of memory for the hard-coded schema, so that if we add/delete other hard-coded schema elements down the road, the map remains useful. All in all it seems extremely fragile and a major pain for compatibility between revisions. Another possibility is to collect all the schema elements at build time, and generate a .c file containing a seed AD map which is hard-coded (and again, is only allowed to grow, no elements modified in place or deleted) so that the core AD map is always the same from run to run. The more I think of it, the more I think this will work. It's essentially the same solution we used to get rid of the ucdata-path item... -- -- 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

RE24 testing call #1 (2.4.26)
by Quanah Gibson-Mount 21 Jun '11

21 Jun '11

Please test RE24 for possible 2.4.26 release. Thanks! --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

2 3

Multicast replication
by Howard Chu 11 Jun '11

11 Jun '11

Was thinking it would be great to use a multicast reliable datagram protocol for replication; that would allow keeping multiple consumers up to date without consuming multiples of the provider's network bandwidth. A decent MRDP would also make for more efficient MMR at the same time. In syncrepl the refresh phase would still occur over a regular TCP session, but the transition to persist phase could include a multicast group membership. This may be better suited to the ldapext mailing list, but thought I'd get some early feedback here first. -- -- 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

slapo-accesslog: resolution of reqStart
by Michael Ströder 10 Jun '11

10 Jun '11

HI! I'm running slapo-memberof and slapo-accesslog together with the fix for ITS#6915. But now when restoring accesslog-LDIF data with slapadd I get: => hdb_tool_entry_put: id2entry_add failed: DB_KEYEXIST: Key/data pair already exists (-30996) slapadd: could not add entry dn="reqStart=20110610110335.000004Z,cn=accesslog" (line=1349625): id2entry_add failed: DB_KEYEXIST: Key/data pair already exists (-30996) Is that because the time resolution is not fine enough? Ciao, Michael.

2 2

client StartTLS issue and return codes enhancement
by Jan Vcelak 31 May '11

31 May '11

Hello everyone, I'm trying to fix one of the OpenLDAP bugs which was reported to Red Hat bugzilla [1]. But I'm not very sure about the correct behavior of client tools '-Z' option. In addition, this is closely related to one enhancement, we would like to propose. Manual page says: > -Z[Z] Issue StartTLS (Transport Layer Security) extended operation. If you > use -ZZ, the command will require the operation to be successful. According to my findings, -Z option causes that StartTLS request is sent as a first operation. And then: 1.) If everything goes well, the client and server will communicate securely. 2.) If the TLS connection is established but the certificate verification is unsuccessful (e.g. hostname doesn't match), the error message is emitted and the communication continues over the TLS channel. 3.) If the server doesn't support TLS (or is configured not to use TLS), StartTLS request is rejected and communication is held insecurely. 4.) If client's TLS configuration is wrong (e.g. TLS_CACERT does not exist), the client connection will fail with 'Can't contact LDAP server (-1)'. The situation we are dealing with is the 4th option. Is this an expected behavior? The problem is, that StartTLS request is sent before processing the certificates. If the server accepts the request, it expects that all following communication is encrypted. But the client cannot process the certificates, ignores the TLS failure and sends the following next unencrypted. The server doesn't understand it, which leads to mentioned error code. The behavior is the same for OpenSSL and Mozilla NSS. And if it is incorrect, there at least two possibilities of fixing it, citing from the bug report: On 2011-05-23 18:09 Rich Megginson wrote: > On 2011-05-23 17:30 Jan Vcelak wrote: > > > 1.) Initialize client certificates before sending StartTLS request. > > I think we would have to change the StartTLS protocol to handle this case. > > > 2.) Close the TLS connection and establish a new unencrypted one when > > this situation happens. > > This is the safest way to go, but I don't know what impact this would have > on existing clients. What do you think about that? Is that expected? Are there a better ways of solving this? If this is an expected behavior, the manual pages should probably mention it. Anyway it would be great, if we could resolve the situation, where the connection to the server fails due to connection error and due to invalid TLS configuration. At the API level and maybe as a return code of the client tools. What do you think about this enhancement? Thank you. Jan [1] https://bugzilla.redhat.com/show_bug.cgi?id=693470

2 1

pcache entry ttl handling
by Ralf Haferkamp 26 May '11

26 May '11

Hi, while working on some issues in slapo-pcache (ITS#6950, 6951, 6953 and 6954). I noticed some (IMO) odd behaviour in how the experiation of cached queries is handled. It seems that pcache happily returns entries for cached queries from the cache even if the query has already expired (ttl is over). It only stops returning results for such a cached query after the periodic consistency checker has run an removed those expired queries. If this is really the desired behaviour I think we should clarify this in the man-page. If it's not we should fix the code. -- Ralf

2 1

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-devel