Viewing Archive.Contrib/1499
Full headers

Major security issue: yes  no

Notes:
Needs HEAD port no apparent interest
Notification:

Date: Tue, 18 Dec 2001 12:38:22 GMT
From: A.J.Martin@qmul.ac.uk
To: openldap-its@OpenLDAP.org
Subject: FTree backend module

Full_Name: Alex Martin
Version: 2.0.18 
OS: Linux  
URL: ftp://ftp.openldap.org/incoming/Alex-Martin-back-ftree-1.0.0pre7-011218.tar.gz
Submission from: (NULL) (138.37.51.209)


The following files contain my FTree module + patches 
 
Alex-Martin-back-ftree-1.0.0pre7-011218.tar.gz
Alex-Martin-ldap-ftree-011218.patch


Here is its README:



                        FTree slapd module
                        ==================


Introduction
============

The FTree slapd module is designed to implement a LDAP DIT using a flexible
memory-based directory-like tree structure. Access to LDAP entries stored in
the
tree is protected by read-write mutexes in order to facilitate efficient 
threaded operation. The tree structure is initiated from the slapd
configuration
file. A basic sample configuration could be:


        database                ftree
        suffix                  "ou=myOrg"
        FtRootDn                ou=myOrg
        FtRootObjectClass       Top


The lines starting with "FtRoot" are internally converted into LDIF format and 
used to initialize the root of the DIT. In this case the root would be set to 
be:

        dn: ou=myOrg
        objectclase: Top


Once initialized, additional entries may added and deleted from backend using
normal LDAP operations.


Entry Types
===========

Although a basic memory-based backend provides useful functionality, a key 
design  feature of the FTree module is the implementation of entries in the 
memory-based structure as polymorphic types. The type information of entries is
defined by the value(s) of the ObjectClass attribute and the sub-classed 
functionality is loaded into the server by means of additional modules (shared 
libraries). When an entry is added to the server its type information is 
determined and compared with those registered by any loaded modules. If it is 
found to match it is associated with the corresponding function table. When a 
type match is not found, basic default behaviour is assumed.       

This method is used to implement the "special" LDAP entry types  Alias,
Referral
and also DynamicObject ( rfc2589 ). The functionality to support these types
may
 be loaded into the server by the addition of the lines:    

        moduleload      back_ftree_alias.la
        moduleload      back_ftree_referral.la
        moduleload      back_ftree_dynamic.la


to the slapd configuration file. 



External Entries
================

The concept of LDAP entries with overloaded functionality is expanded further 
to allow additional user-defined types. The intention here is to provide an 
API which can facilitate the addition of more modular functionality. 

One use of this concept is the integration of external information sources
e.g. scripts, files and other LDAP servers into the DIT. At a basic level
this can be thought of as a flexible version of some of the existing 
OpenLDAP backends i.e. back-shell, back-ldap. However, unlike the existing
backends, multiple entries corresponding to these external info sources        

may be freely added and deleted from a server. The schema defining these 
types are contained in the file 
%SYSCONFIGDIR%/schema/openldap-ftree.schema.  

This functionality is loaded via the modules:


        moduleload      back_ftree_external.la
        moduleload      back_ftree_exec.la
        moduleload      back_ftree_ldap.la   

External is an abstract base class whose methods are implemented by the Exec
and
Ldap classes.Examples of their use are provided in the files exec-example.ldif
and ldap-example.ldif in the demos directory %SYSCONFDIR%/demos:  


	dn: in=loadaverage1, dc=localhost, dc=localdomain, ou=myOrg  
	objectClass: exec
	objectClass: external
	command: loadaverage
	arguments: in=loadaverage1,dc=localhost,dc=localdomain,ou=myOrg

This entry specifies the external info source is a command "loadaverage"
with arguments "in=loadaverage1,dc=localhost,dc=localdomain,ou=myOrg". 
For security reasons, the path used to locate commands is defined by a class 
variable which is set by the "execpath" variable in the configuation file. 
The API used when forking the command is the same as that used in the standard
back-shell backend module.

A similar configuration specifying another LDAP server as an info source
is:

	dn: dc=localhost1, dc=localdomain, ou=myOrg
	objectClass: ldap
	objectClass: external
	ref: ldap://localhost:2171/dc=localhost,dc=localdomain,ou=myOrg

Here "ref" specifies the URL of the external server using the same 
syntax as a referral.



Caches
======

An additional feature provided by the FTree backend is the ability to 
setup a cache of an external info source.  The basic functionality is 
provided by abstract classes "Cache"  and "ThreadedCache".  "CacheSearches"
implements a simple non-threaded model where search results are cached. 
Several threaded cache models are provided "CachePeriodically", where a thread
periodically updates the cache from its source and "CacheFromStream", where  
th

Followup 1

Date: Thu, 27 Dec 2001 12:15:19 -0800
To: A.J.Martin@qmul.ac.uk
From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
Subject: Re: FTree backend module  (ITS#1499)
Cc: openldap-its@OpenLDAP.org

Alex,

Your contribution is intriguing.  I'm busy with other things
at the moment, so cannot provide detailed review yet.

I note your backend appears to be implemented against 2.0.
Before the backend could be committed, it would need to be
ported to HEAD.  The HEAD backend just went through a major
revamping, but likely is stable enough now to code against.

If you have time to forward port to HEAD, please do.

Regards, Kurt