openldap-devel

openldap-devel@openldap.org

2 participants
1426 discussions

Re: Config file statement ordering (Was: (ITS#4848) Another slapd startup segfault)
by Howard Chu 26 Feb '07

26 Feb '07

Pierangelo Masarati wrote: > For back-meta, I'd like to create children entries for each target; in > this case, an overlay with specific per-target behavior, would need to > either create a similar tree, or to append entries to targets'. This is > really going to mess up back-config. Still, I think having separate > entries makes sense. That's how I made, for example, the monitor > interface to "foobar" overlay... Speaking of which, ITS#4789, were you actually suggesting that back-monitor also use olcDatabase={x}foo to name its database entries? That would change its apparent behavior quite a bit from 2.3. As I mentioned before, I chose not to use a cn=Databases container in back-config because I didn't want to have to deal with creating a lot of do-nothing infrastructure entries. Philosophically I also prefer RDNs that use task-specific attributes; I've always thought cn was too overused... And if we're using olcDatabase, then e.g. olcDatabase={1}foo,cn=databases,cn=monitor is just redundant information, we already know foo is a database so we don't need the container to remind us of that. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc Chief Architect, OpenLDAP http://www.openldap.org/project/

2 1

Config file statement ordering (Was: (ITS#4848) Another slapd startup segfault)
by Pierangelo Masarati 24 Feb '07

24 Feb '07

ando(a)sys-net.it wrote: > The above had nothing to do with your problem. Your problem is related > to the fact that you intermixed overlay and database configuration > statements, so the idletimeout statement after the accesslog overlay > instantiation was causing invalid memory write (beyond the private data > of the accesslog overlay instead of in the private data of the bdb > database) resulting in heap corruption. > > Maybe it hasn't been stressed enough, but the order of directives is: I believe the problem is here: ========================================================================= diff -u -r1.341.2.25 config.c --- servers/slapd/config.c 8 Feb 2007 12:31:24 -0000 1.341.2.25 +++ servers/slapd/config.c 24 Feb 2007 13:29:42 -0000 @@ -308,13 +308,28 @@ return(0); } if(arg_type & ARG_OFFSET) { - if (c->be && (!overlay_is_over(c->be) || - ((slap_overinfo *)c->be->bd_info)->oi_orig == c->bi)) - ptr = c->be->be_private; - else if (c->bi) + if ( c->be ) { + if (!overlay_is_over(c->be) || + ((slap_overinfo *)c->be->bd_info)->oi_orig == c->bi) + { + ptr = c->be->be_private; + + } else { + snprintf( c->msg, sizeof( c->msg ), + "<%s> statement outside scope " + "(after overlay?)", + c->argv[0] ); + Debug(LDAP_DEBUG_CONFIG, "%s: %s!\n", + c->log, c->msg, 0); + return(ARG_BAD_CONF); + } + + } else if ( c->bi ) { ptr = c->bi->bi_private; - else { - snprintf( c->msg, sizeof( c->msg ), "<%s> offset is missing base pointer", + + } else { + snprintf( c->msg, sizeof( c->msg ), + "<%s> offset is missing base pointer", c->argv[0] ); Debug(LDAP_DEBUG_CONFIG, "%s: %s!\n", c->log, c->msg, 0); ========================================================================= that is, if both the database and the overlay allow back-config, there are cases in which config_set_vals() can be called with (arg_type & ARG_OFFSET) and the c->be points to the database's structure while c->bi points to the overlay's structure, and the config statement refers to the database although appearing after the overlay's instantiation. This is Bad (TM) and should be avoided. However, for example, I have special needs in back-meta that require to allow overlay instantiation __before__ the database configuration is complete (in that case, I need an overlay to be instantiated before targets are defined, so that the overlay can get per-target configuration parameters much like the underlying database does). This may defer introduction of back-config support for back-meta. Comments? Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

2 3

openldap-2.4.4alpha available [corrected]
by OpenLDAP Project 17 Feb '07

17 Feb '07

See http://www.openldap.org/software/download/ Please report problems using the Issue Tracking System. http://www.openldap.org/its/ -- OpenLDAP Project [previous post had incorrect version number]

1 0

openldap-2.4.3alpha available
by OpenLDAP Project 17 Feb '07

17 Feb '07

See http://www.openldap.org/software/download/ Please report problems using the Issue Tracking System. http://www.openldap.org/its/ -- OpenLDAP Project

1 0

liblber additions
by Howard Chu 16 Feb '07

16 Feb '07

We have a port of GNUtls support for OpenLDAP underway. Their certificate DN parsing APIs are pretty bad. Rather than use their APIs I've modified libldap's ldap_X509dn2bv function to take a DN in DER form, directly from the certificate, and parse it directly using liblber. For that purpose I've needed to add a few new tag definitions as well as a decoder for BER-encoded OIDs. Not sure if these should be ber_pvt definitions or just public. Since a typical LDAP program rarely is faced with real ASN.1 structures it seems we don't need to expose them. Comments? Also as a side-effect, we can support certificate parsing, to implement the certificate-related component matching rules, without needing OpenSSL or any other crypto library. I.e., I have a complete certificate parser using liblber. (The code is trivial. We probably should have done this from the start...) Something I'd like to revisit - when using liblber and parsing in-place, our parse is destructive because we NUL-terminate all octet strings. I'm considering changing this behavior, to leave the original BER data unmodified. At present it seems this change would have the greatest effect on Debug output, where we pass ber->bv_val's for printing without any further qualification. Any thoughts? as an aside - the fact that GNUtls' certificate DN handling is broken is worrisome, since issuer DNs are an integral part of certificate path validation. Until we have time to dig deeper into that code and patch all the problems, it would be a good idea to avoid using GNUtls. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc Chief Architect, OpenLDAP http://www.openldap.org/project/

2 1

Re: commit: ldap/servers/slapd sasl.c sl_malloc.c connection.c proto-slap.h
by Howard Chu 14 Feb '07

14 Feb '07

hyc(a)OpenLDAP.org wrote: > Update of /repo/OpenLDAP/pkg/ldap/servers/slapd > > Modified Files: > sasl.c 1.245 -> 1.246 > sl_malloc.c 1.40 -> 1.41 > connection.c 1.393 -> 1.394 > proto-slap.h 1.715 -> 1.716 > > Log Message: > Added "slapd" rewrite map handler, connection_fake_init2 to use existing > tmpmemctx without reinitializing The documentation for this feature presents a bit of a problem, since most of the functionality of librewrite is documented in slapo-rwm(5). When SLAP_AUTH_REWRITE is defined (which it is, whenever --enable-rewrite is used) then all of librewrite's capabilities really should be in the main slapd documentation. In the meantime, here's an example usage: rwm-rewriteMap slapd cn2dn "ldap:///dc=example,dc=com?dn?sub?(&(objectclass=person)" rwm-rewriteContext bindDN rwm-rewriteRule "^(cn=[^,]+),.*" "${cn2dn(($1)))}" ":@I" This (stupid) example allows a user with a long DN to bind using just their RDN plus any subset of the DB suffix. E.g, a user with DN cn=Joe Bob,ou=Team1,ou=Teams,ou=Divisions,dc=example,dc=com could bind with just cn=Joe Bob,dc=example,dc=com -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc Chief Architect, OpenLDAP http://www.openldap.org/project/

3 4

Re: commit: ldap/servers/slapd/schema dyngroup.schema
by Pierangelo Masarati 09 Feb '07

09 Feb '07

hyc(a)OpenLDAP.org wrote: > Update of /repo/OpenLDAP/pkg/ldap/servers/slapd/schema > > Modified Files: > dyngroup.schema 1.9 -> 1.10 > > Log Message: > Revert memberURL back to STRUCTURAL - test044 breaks otherwise AFAIR, there's no need in slapo-dynlist(5) code for 'groupOfURLs' (not 'memberUrl' :) to be STRUCTURAL; what test044 does is simply add some dynamic groups, so reworking the test data should suffice, if you believe that class should be AUXILIARY. Do you want me to look at that test with the above change? p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

2 1

Re: commit: ldap/servers/slapd bconfig.c
by Howard Chu 07 Feb '07

07 Feb '07

hyc(a)OpenLDAP.org wrote: > Update of /repo/OpenLDAP/pkg/ldap/servers/slapd > > Modified Files: > bconfig.c 1.255 -> 1.256 > > Log Message: > ITS#4752 add undo for schema entries. back-config was already cleaning up failed Adds for databases and overlays. This commit adds another special case for schema entries. A general solution doesn't really exist, since some attributes just don't support a Delete operation. But this covers the key object types. E.g. deleting a moduleLoad directive will be a major problem until we add a lot of unregister / destroy functions which currently don't exist. (An overlay like syncprov dynamically registers a schema, a control and the overlay itself. Each of those needs a tear-down function. The Modify handler does a more thorough job of undoing things. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

syncrepl
by Howard Chu 07 Feb '07

07 Feb '07

ITS#4618, 4623, 4626 and 4703 all basically have to do with trying to use multiple replication contexts with a single provider. This is a behavior that the 2.3 syncprov implementation just wasn't designed for; it was meant to handle only a single context. Looking at the ideas in 2.2's syncrepl, it might have gone in the direction of solving these problems if it weren't weighed down by so many insurmountable design and implementation flaws. 2.2 probably tried to do too much too soon, and got waylaid by the devil in the details. At this point, this solution for multiple contexts presents itself: 1) We assign distinct searchbases to each context. 2) Every distinct source of changes must have its own unique rid. E.g., if a database is a provider for a context, it must have an rid. Every consumer within its namingContext must have their own rid's just as before. (The new requirement here is assigning rid's to providers that are masters of their data.) 3) Currently the provider hands a consumer a cookie consisting of the rid that the consumer supplied, plus a single contextCSN from the provider. This single contextCSN is inadequate for accurately capturing all of the changes that may come from multiple sources in a namingContext. Instead, the provider will send out a cookie consisting of multiple rid,CSN pairs - one for every rid of the provider's that resides in the consumer's search space. This is the only reliable way to make sure that all changes are tracked and propagated. This says that in general, rids should not need to be configured on consumers - they should be dictated solely by the providers. It may be a good idea to allow them to be configured on consumers as an override, but for now that seems unimportant. So: 1) the provider must have its own unique rid configured 2) the consumer's rid is optional 3) the provider must be told about all of the consumers living under it 4) the provider must aggregate all of the consumer cookies under it with its own context info when generating a cookie for its own consumers Currently slapd treats an entire database as read-only when it has a consumer configured on it. This raises the question of how to allow multiple consumers in a single context - should we allow multiple consumers per DB, as 2.2 tried (and failed) to do, or should we continue with the current approach of one consumer per DB, and use glue to collect multiple consumers under one roof? -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

3 9

slapo-dynlist desgin question(s)
by Quanah Gibson-Mount 07 Feb '07

07 Feb '07

Stanford is looking at implementing groups into our LDAP servers, and in particular, looking at using slapo-dynlist. However, it does not behave as I expected it to. Basically, it uses the credentials of whomever bound to determine the membership list. This means I would have to give access to a privileged attribute to those who wished to use groups, which is exactly what I'm trying to avoid. What I wanted to do, was specifically control the access to the group objects themselves. If an entity has access to the group object, they would then be able to see all current members of the group. I believe this would mean adding functionality to slapo-dynlist to where it uses the rootdn to perform the internal search instead of the credentials. Would it be possible to have this sort of addition? --Quanah -- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

3 34

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-devel