openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

(ITS#6773) Per-connection extra stuff
by masarati＠aero.polimi.it 04 Jan '11

04 Jan '11

Full_Name: Pierangelo Masarati Version: HEAD OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (188.153.18.39) Submitted by: ando I need to add extra stuff to the Connection structure, to save persistent data across operations. Right now, I'm planning to use it to support RFC 3829 authzid control. <http://www.openldap.org/lists/openldap-devel/201101/msg00005.html> Probably, this can collect other specific stuff like Paged Results c_pagedresults_state, Netscape plugin c_extensions, transactions c_txn_* and more. The patch is straightforward (I'm reproducing it here only for illustrative purposes): -- diff -u -r1.899 slap.h --- servers/slapd/slap.h 31 Dec 2010 19:02:41 -0000 1.899 +++ servers/slapd/slap.h 4 Jan 2011 13:15:07 -0000 @@ -2811,6 +2811,16 @@ /* * represents a connection from an ldap client */ + +/* This is only a header. Actual users should define their own + * structs with the ce_next / ce_key fields at the top and + * whatever else they need following. + */ +typedef struct ConnExtra { + LDAP_SLIST_ENTRY(ConnExtra) ce_next; + void *ce_key; +} ConnExtra; + /* structure state (protected by connections_mutex) */ enum sc_struct_state { SLAP_C_UNINITIALIZED = 0, /* MUST BE ZERO (0) */ @@ -2927,6 +2937,8 @@ void *c_extensions; /* Netscape plugin */ + LDAP_SLIST_HEAD(c_e, ConnExtra) c_extra; /* anything the backend needs */ + /* * Client connection handling */ -- Unless there are objections, I'd commit it. p.

1 0

Re: (ITS#6762) cloak overlay only works on first search entry
by masarati＠aero.polimi.it 04 Jan '11

04 Jan '11

> Full_Name: Hallvard B Furuseth > Version: 2.4.23, HEAD > OS: > URL: > Submission from: (NULL) (129.240.6.233) > Submitted by: hallvard > > > The cloak overlay only works on the first entry returned from a search. > Then it removes the callback, and the remaining attributes are > uncloaked. > > I checked this by removing the call to slap_freeself_cb() and the > setting of sc_cleanup, then it worked. And probably got a leak > somewhere, but I don't have time to find the right fix now. Should be fixed in HEAD. Please test. Thanks, p.

1 0

a problem of authentication fail in Ubuntu 10.04,slapd 2.4.21
by cn_gd＠126.com 04 Jan '11

04 Jan '11

hi all, I 'm install slapd follow bellow steps in ubuntu 10.04 lucid strictly: 1. apt-get install slapd * slapd -V @(#) $OpenLDAP: slapd 2.4.21 (Aug 10 2010 17:08:36) $ buildd@yellow:/build/buildd/openldap-2.4.21/debian/build/servers/slapd* 2. dpkg-reconfigure slapd 3.edit /etc/ldap/slapd.d/cn\=config.ldif 4. cat /etc/ldap/slapd.d/cn\=config.ldif dn: cn=config objectClass: olcGlobal cn: config olcArgsFile: /var/run/slapd/slapd.args olcLogLevel: none olcPidFile: /var/run/slapd/slapd.pid structuralObjectClass: olcGlobal dn: olcDatabase=bdb,cn=config objectClass: olcDatabaseConfig objectClass: olcBdbConfig olcDatabase: bdb olcSuffix: "dc=cg,dc=scsio,dc=ac,dc=cn" olcDbDirectory: /home/az/openldap-data olcRootDN: "cn=Manager,dc=cg,dc=scsio,dc=ac,dc=cn" olcRootPW: secret 4. /etc/init.d/slapd restart All step're OK,then I run bellow to test it: 5. ldapsearch -x -D "cn=Manager,dc=cg,dc=scsio,dc=ac,dc=cn" -w "secret" -H ldap://cg.scsio.ac.cn and it show that error: *ldap_bind: Invalid credentials (49) **I try again and again,but it'still the same.( using slappasswd to change it also turn to same problem). I wonder what's go wrong.any help would be greatly appreciated.Thank you in advance! ** *

1 0

(ITS#6772) slapcommon.c:495:9: error: �SLAPMODIFY� undeclared
by michael＠stroeder.com 04 Jan '11

04 Jan '11

Full_Name: Michael Ströder Version: RE24 OS: Linux URL: Submission from: (NULL) (84.128.246.210) Currently there seems to be something missing (did cvs up several times): cc -g -O4 -I../../include -I. -I./slapi -I. -I../../include -I/usr/include -I/usr/include -I/usr/include -I/usr/include -DDEVEL -DSLAP_CONFIG_DELETE -c -o slapcommon.o slapcommon.c slapcommon.c: In function slap_tool_init: slapcommon.c:495:9: error: SLAPMODIFY undeclared (first use in this function) slapcommon.c:495:9: note: each undeclared identifier is reported only once for each function it appears in make[2]: *** [slapcommon.o] Error 1 make[2]: Leaving directory `/usr/src/michael/openldap/OPENLDAP_REL_ENG_2_4/openldap/servers/slapd' make[1]: *** [all-common] Error 1 make[1]: Leaving directory `/usr/src/michael/openldap/OPENLDAP_REL_ENG_2_4/openldap/servers' make: *** [all-common] Error 1

1 0

(ITS#6771) Feature request: support for RFC 3829 authzid control
by masarati＠aero.polimi.it 04 Jan '11

04 Jan '11

Full_Name: Pierangelo Masarati Version: irrelevant OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (188.153.18.39) Submitted by: ando A simple module that implements RFC 3829 server-side is committed in contrib/slapd-modules/authzid; it only works for single-step bind. Extension to multi-step bind may not be trivial. p.

1 0

(ITS#6770) Proxy authorization fails with SASL-GSSAPI
by jwinius＠umrk.nl 03 Jan '11

03 Jan '11

Full_Name: Jaap Winius Version: 2.4.23-7 OS: Debian squeeze URL: Submission from: (NULL) (2001:888:10:d5f::2) Proxy authorization works with SIMPLE binds, as well as with SASL binds using various other mechanisms, but not with SASL and GSSAPI. In that case it may only work initially, but eventually the problem is that, for no apparent reason, the consumer instead attempts to use a SIMPLE bind to authenticate itself to the provider. Naturally, this fails. For detailed background and debugging info, see this thread: http://www.openldap.org/lists/openldap-technical/201101/msg00002.html

1 0

(ITS#6769) Slapd fails to start when olcDbURI attribute is used
by jwinius＠umrk.nl 03 Jan '11

03 Jan '11

Full_Name: Jaap Winius Version: 2.4.23-7 OS: Debian squeeze URL: Submission from: (NULL) (2001:888:10:d5f::2) When attempting configuring slapd as a consumer with proxy authorization, it refuses to start up after the olcDbURI attribute is added to the olcDatabase=ldap entry: ===BEGIN====================== slapd-chain: first underlying database "olcDatabase={0}ldap,olcOverlay={0}chain,olcDatabase={1}hdb,cn=config" cannot contain attribute "olcDbURI". config error processing olcDatabase={0}ldap,olcOverlay={0}chain,olcDatabase={1}hdb,cn=config: slapcat: bad configuration file! ===END======================== This situation occurs with both the SIMPLE and SASL-GSSAPI bind configurations that I've tested. The solution is to apply this patch: ftp://ftp.openldap.org/incoming/pierangelo-masarati-2010-04-29-chain.1.patch For background, see also this thread: http://www.openldap.org/lists/openldap-technical/201011/msg00124.html As you can see, the issue has been known for some time, but I don't know if a bug report has been submitted for it yet, so I thought this would do no harm.

1 0

Re: (ITS#6660) paged result searches fail to deallocate memory until slapd shutdown
by quanah＠zimbra.com 03 Jan '11

03 Jan '11

--On Thursday, September 30, 2010 11:31 AM +0000 hyc(a)symas.com wrote: Using the latest patch for this issue from HEAD, the issue is no longer present. Using 14 searches (7 full db/7 paged results with a filter), the size of the slapd process is persistent across multiple runs, rather than growing substantially with each iteration of searches. This is using the same system and same database when the problem was originally filed. --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

1 0

Re: (ITS#6664) Server control forwarding in back_meta and back_ldap
by masarati＠aero.polimi.it 03 Jan '11

03 Jan '11

> back_meta and back_ldap should forward server controls that clients use in > their > queries to the corresponding external LDAP servers. > > For example, the inhability to send controls to external servers currently > causes that RFC2696 paged results control cannot be used, so it is > impossible to > retrieve more results for a query than the page size configured in the > external > server, which often is not a big number. I've patched back-meta in HEAD: if you add the "client-pr" directive, it will perform the client-side of RFC 2696 paged results (either always, with the specified page size, or in response to unsolicited paged results response). This will be totally transparent to the actual client, so the client no longer needs to perform paged results itself. Please test and report. Thanks, p.

1 0

(ITS#6768) NULL OldDN in modrdn operation kill slapd server
by sergeyfd＠gmail.com 03 Jan '11

03 Jan '11

Full_Name: Serge Dubrouski Version: 2.4.23 OS: RedHat ES 5.5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (208.30.65.103) I ound that ldp.exe tool that comes with Windows is able to successfully kill OpenLDAP 2.4.23 slapd server when one tries to modify DN and submits an empty old DN. No binding is necessary so even anonymous user can easily run a DOS attach against OpenLDAP. Log files in openldap show this: Dec 29 15:19:32 ottawa slapd[11818]: conn=1000 op=2 do_modrdn Dec 29 15:19:32 ottawa slapd[11818]: do_modrdn: dn () newrdn (C=US) newsuperior () Dec 29 15:19:32 ottawa slapd[11818]: >>> dnPrettyNormal: <> Dec 29 15:19:32 ottawa slapd[11818]: <<< dnPrettyNormal: <>, <> Dec 29 15:19:32 ottawa slapd[11818]: >>> dnPrettyNormal: <C=US> Dec 29 15:19:32 ottawa slapd[11818]: <<< dnPrettyNormal: <c=US>, <c=us> Dec 29 15:19:32 ottawa slapd[11818]: conn=1000 op=2 MODRDN dn=""

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