OpenLDAP
Up to top level
Build   Contrib   Development   Documentation   Historical   Incoming   Software Bugs   Software Enhancements   Web  

Logged in as guest

Viewing Contrib/5305
Full headers

From: josemarcodelarosa@gmail.com
Subject: Contribware: Two overlays for implementing NESTED dynamic groups
Compose comment
Download message
State:
0 replies:
5 followups: 1 2 3 4 5

Major security issue: yes  no

Notes:

Notification:


Date: Thu, 3 Jan 2008 20:29:02 GMT
From: josemarcodelarosa@gmail.com
To: openldap-its@OpenLDAP.org
Subject: Contribware: Two overlays for implementing NESTED dynamic groups
Full_Name: Jose Marco de la Rosa
Version: 2.3.39
OS: Kubuntu 7.10
URL: ftp://ftp.openldap.org/incoming/Jose-Marco-de-la-Rosa-nestedAggregateAttr-080103.tgz
Submission from: (NULL) (80.25.122.131)


Two overlays that implement dynamic group classes defined with URL attributes
and allowing nesting.

- The first one is an extension of th overlay expandURL but allowing nesting

- The second one changes the way groups are constructed in a more powerful way

Examples of functioning follow for each version and are included in the
overlays
code archives (.c)

The tarball Jose-Marco-de-la-Rosa-nestedAggregateAttr-080103.tgz was uploaded
to openldap's server and it includes a webpage with further detail in the
implementation and configuration of the overlay.

Code files are appropriately linked in the web page mentioned (all is included
in the tarball: there are no external references in the webpage).

Both search and compare operations were implemented

I hope you like it...

#######################################################
First overlay: nestedAggregateAttrDN:

* SYNTAX:
 * 
 * In slapd.conf :
 *   overlay nestedAggregateAttrDN
 *   nestedAggregateAttrDN  <objectClass> <source-attribute>
<destination-attribute> [[<maximum-depth>] <TTL>]
 * Where:
 *      <objectClass> specifies the class that should expand.
 *      <source-attribute> establishes the attribute that contains
information 
 *              about other entries where to gather destination attribute values
from.
 *      <destination-attribute> establishes the attribute that should
present
all the gathered values.
 *      <maximum-depth> establishes the maximum nesting depth level. If
not
specified, it defaults 
 *              to 0 which means no nesting is allowed (not even one level).
 *      <TTL> establishes the maximum time allowed to serve the query. You
should take into account that:
 *            If different TTLs are set for the different configurations the
minimum 
 *            will be used for all configurations.
 *            The TTL affects ALL searches done when the overlay is active and
not only 
 *            those related to the configured clases.
 * 
 * 
 * EXAMPLE:
 * 
 * NOTE: you will probably need/want to define some attributes and classes in
your schema
 * example.schema:
 * -------------------
 * objectIdentifier YOUR_ENTERPRISE_Root 1.3.6.1.4.1.<somenumber>
 * objectIdentifier YOUR_ENTERPRISE_LDAP YOUR_ENTERPRISE_Root:3
 * objectIdentifier YOUR_ENTERPRISE_LDAPattributeType YOUR_ENTERPRISE_LDAP:1
 * objectIdentifier YOUR_ENTERPRISE_LDAPobjectClass YOUR_ENTERPRISE_LDAP:2
 * 
 * # Attribute type for new classes
 * 
 * attributetype ( YOUR_ENTERPRISE_LDAPattributeType:1
 *  NAME 'subgroupDN'
 *  DESC 'DN of a aggregable entry'
 *  SUP distinguishedName )
 *
 * # Classes for using overlay nestedAggregateAttrDN
 * 
 * objectclass ( YOUR_ENTERPRISE_LDAPobjectClass:1
 * 	NAME 'subgroupedDNGroup'
 * 	DESC 'Sample class for nestedAggregateAttrDN (experimental purpose)'
 * 	SUP top STRUCTURAL
 * 	MUST cn
 * 	MAY ( member $ subgroupDN $ cn $ ou $ o $ description ) ) 
 * 
 * 
 * slapd.conf:
 * -------------------
 * overlay nestedAggregateAttrDN
 * # Configure class: subgroupedDNGroup
 * # Source attribute: subgroupDN
 * # Aggregated attribute: member
 * # Max depth in nesting: 4
 * # TTL: 5 sec
 * nestedAggregateAttrDN  subgroupedDNGroup subgroupDN member 4 5
 *  
 * 
 * ldif:
 * -------------------
 * 
 * # Static1
 * dn: cn=Static1,dc=test
 * cn: Static1
 * objectClass: groupOfNames
 * member: cn=person1,dc=test
 * member: cn=person2,dc=test
 * 
 * # Static2
 * dn: cn=Static2,dc=test
 * cn: Static2
 * objectClass: groupOfNames
 * member: cn=person3,dc=test
 * member: cn=person4,dc=test
 * 
 * # SubgroupedLevel1
 * dn: cn=SubgroupedLevel1,dc=test
 * cn: SubgroupedLevel1
 * objectClass: subgroupedDNGroup
 * subgroupDN: cn=Static1,dc=test
 * 
 * # SubgroupedLevel2
 * dn: cn=SubgroupedLevel2,dc=test
 * cn: SubgroupedLevel2
 * objectClass: subgroupedDNGroup
 * subgroupDN: cn=SubgroupedLevel1,dc=test
 * subgroupDN: cn=Static2,dc=test
 * 
 * 
 * -------------------
 * 
 * ldapsearch -x -b "SubgroupedLevel2,dc=test" will return
 * 
 * # SubgroupedLevel2
 * dn: cn=SubgroupedLevel2,dc=test
 * cn: SubgroupedLevel2
 * objectClass: subgroupedDNGroup
 * subgroupDN: cn=SubgroupedLevel1,dc=test
 * subgroupDN: cn=Static2,dc=test
 * member: cn=person1,dc=test
 * member: cn=person2,dc=test
 * member: cn=person3,dc=test
 * member: cn=person4,dc=test
 *
 * 
 * IMPORTANT: this overlay conflicts with nestedAggregateAttrURL.
 * 		if both are active, some searches don't behave as expacted!
 * 		Specifically, if you turn both overlays on and search for
 * 		'entries with member=<some member value>' won't work properly
 * 		for one of the overlays (the firstly activated one)
 */  


#######################################################
Second overlay: nestedAggregateAttrURL:

 * SYNTAX:

Message of length 9008 truncated

Followup 1

Download message
Date: Thu, 03 Jan 2008 14:46:14 -0800
From: Howard Chu <hyc@symas.com>
To: josemarcodelarosa@gmail.com
CC: openldap-its@openldap.org
Subject: Re: (ITS#5305) Contribware: Two overlays for implementing NESTED
 dynamic	groups
josemarcodelarosa@gmail.com wrote:
> Full_Name: Jose Marco de la Rosa
> Version: 2.3.39
> OS: Kubuntu 7.10
> URL: ftp://ftp.openldap.org/incoming/Jose-Marco-de-la-Rosa-nestedAggregateAttr-080103.tgz
> Submission from: (NULL) (80.25.122.131)
> 
> 
> Two overlays that implement dynamic group classes defined with URL
attributes
> and allowing nesting.
> 
> - The first one is an extension of th overlay expandURL but allowing
nesting
> 
> - The second one changes the way groups are constructed in a more powerful
way

>  * IMPORTANT: this overlay conflicts with nestedAggregateAttrDN.
>  * 		if both are active, some searches don't behave as expacted!
>  * 		Specifically, if you turn both overlays on and search for
>  * 		'entries with member=<some member value>' won't work properly
>  * 		for one of the overlays (the firstly activated one)

Seems there's really no need for the nestedAggregateAttrDN overlay, since that 
is just a proper subset of a URL. I.e., anywhere you would use a simple DN is 
just a case of subGroupURL: ldap:///<dn>??base

-- 
   -- 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/



Followup 2

Download message
Date: Fri, 4 Jan 2008 14:07:36 +0100
From: "=?ISO-8859-1?Q?Jos=E9_Marco?=" <josemarcodelarosa@gmail.com>
To: openldap-its@openldap.org
Subject: Re: (ITS#5305) Contribware: Two overlays for implementing NESTED dynamic groups
------=_Part_27665_28430263.1199452056921
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

  Yes, you are completely right.  The only reason I can think of using the
DN version is because you are forced by your schema (attribute types for the
expansion source attribute differ). I emphasize that the implementation of
both is quite different. The DN version uses recursivity while the URL
version relies in slapd's search-reply mechanism. I just added the first one
as an example.

  URL version is much more powerful and more elegant. You suggested
subGroupURL: ldap:///<dn>??base, but even subGroupURL: ldap:///<dn>
works ok
(if I remember right).

------=_Part_27665_28430263.1199452056921
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

<br>&nbsp; Yes, you are completely right.&nbsp; The only reason I
can think of using the DN version is because you are forced by your schema
(attribute types for the expansion source attribute differ). I emphasize that
the implementation of both is quite different. The DN version uses recursivity
while the URL version relies in slapd&#39;s search-reply mechanism. I just
added the first one as an example.
<br><br>&nbsp; URL version is much more powerful and more
elegant. You suggested subGroupURL: ldap:///&lt;dn&gt;??base, but even
subGroupURL: ldap:///&lt;dn&gt; works ok (if I remember
right).<br><br>

------=_Part_27665_28430263.1199452056921--



Followup 3

Download message
Date: Sat, 05 Jan 2008 11:15:50 +0100
From: Pierangelo Masarati <ando@sys-net.it>
To: josemarcodelarosa@gmail.com
CC: openldap-its@openldap.org
Subject: Re: (ITS#5305) Contribware: Two overlays for implementing NESTED
 dynamic groups
josemarcodelarosa@gmail.com wrote:

>   Yes, you are completely right.  The only reason I can think of using the
> DN version is because you are forced by your schema (attribute types for
the
> expansion source attribute differ). I emphasize that the implementation of
> both is quite different. The DN version uses recursivity while the URL
> version relies in slapd's search-reply mechanism. I just added the first
one
> as an example.
> 
>   URL version is much more powerful and more elegant. You suggested
> subGroupURL: ldap:///<dn>??base, but even subGroupURL:
ldap:///<dn> works ok
> (if I remember right).

According to Section 3 of RFC 4516, if <scope> is omitted, a scope of
"base" is assumed.

p.



Ing. Pierangelo Masarati
OpenLDAP Core Team

SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
---------------------------------------
Office:  +39 02 23998309
Mobile:  +39 333 4963172
Email:   pierangelo.masarati@sys-net.it
---------------------------------------




Followup 4

Download message
Date: Sat, 05 Jan 2008 12:40:00 +0100
From: Pierangelo Masarati <ando@sys-net.it>
To: josemarcodelarosa@gmail.com
CC: openldap-its@openldap.org
Subject: Re: (ITS#5305) Contribware: Two overlays for implementing NESTED
 dynamic	groups
Jose,

few preliminary comments:

- you coded your contribution for OpenLDAP 2.3; however, since it
configures as a new feature, it should be coded for OpenLDAP 2.4 (better
for HEAD), as 2.3 is feature-frozen ever since.  This comment may appear
trivial, but right now your contribution does not compile with HEAD/re24
because of some internal API changes.

- the coding style you used does not conform to that of the OpenLDAP
project.  Although this is usually only loosely enforced, you used
things we're a bit picky about, like C++-style comments, and late
declarations; if you compile with enough warnings (e.g., with gcc, with
-Wall -pedantic) you'll see that in many cases functions are not
returning when a return value is expected or vice-versa; incorrect
formats are used for (long) integers, pointers and so.  Also, I note
that besides being a totally new contribution, many of the comments are
already no longer aligned with the code.

- according to agreed development lines, new contributions should always
provide back-config support (this can be added later, if and when the
rest works as expected)

- with respect to the possible improvements you indicate, I think:
  1) permission checking should occur along the lines of, e.g.,
slapo-dynlist(5), honoring dgIdentity and dgAuthz.
  2) avoiding unnecessary expansion would probably be mandatory for
production use
  3) use back-config rather than naive in-database configuration using
an ordinary database

- The build instructions you provide are incorrect: you suggest to place
the source in servers/slapd/overlays/, and to modify statover.c; this is
a generated file, so it should never be modified.  You should rather
suggest to place the sources in an arbitrary directory (it could be
contrib/slapd-modules/nestedAggregateAttr as soon as your contribution
enters the official distribution) and build it as a run-time module.

- you should rather eliminate duplicate values from result sets (much
like slapo-dynlist(5) does) as they are not allowed by the definition of
the "member" attribute, which has a distinguishedNameMatch EQUALITY rule.

- instead of copying compare_entry(), you should rather ask to make the
one in servers/slapd/compare.c non-static

- since the "OR" operator in filters allows more than 2 operands, I
think your filter combination strategy could be optimized by simply
defining a combine_filters() function that counts the number of filter
strings in the array and creates a filter like "(|(f1)(f2)(f3)...)"

- in check_filter(), you compare strings; you should rather compare
pointers to AttributeDescription structures.

- in nestedAggregateAttrURL_search() you don't need to run str2filter()
on op->ors_filterstr, since an exploded filter is already available in
op->ors_filter

- strings[] containing "(objectClass=<ocname>)" could be prepared once
for all during config; it would save a lot of mallocs (BTW: use the slab
for operation-spanning allocation).

- I would recommend you do some consistent checking of return values
before dereferencing pointers.

- I would recommend that you either remove or turn into useful standard
debugging the plethora of non-standard messages you added.  Use
LDAP_DEBUG_ARGS to mark entering/exiting functions (and logging useful
args); use LDAP_DEBUG_TRACE to trace operations; use slap_loglevel_get()
to register friendly names for specific log subsystems (you'll get back
the number to compare with ldap_debug).

- with respect to the OID for the test schema items, you'll get an OID
arc in the experimental OID namespace of the OpenLDAP project as soon as
your contribution is incorporated.

p.



Ing. Pierangelo Masarati
OpenLDAP Core Team

SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
---------------------------------------
Office:  +39 02 23998309
Mobile:  +39 333 4963172
Email:   pierangelo.masarati@sys-net.it
---------------------------------------




Followup 5

Download message
Date: Tue, 22 Jan 2008 20:46:36 +0100
From: Pierangelo Masarati <ando@sys-net.it>
To: openldap-its@openldap.org
Subject: (ITS#5305)
From a private message the contributor sent me, it appears he's not
working at this any more, and he doesn't intend to take care of the
reviews.  So I suggest his contribution goes to "contrib", in case
anyone finds it useful.

p.



Ing. Pierangelo Masarati
OpenLDAP Core Team

SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
---------------------------------------
Office:  +39 02 23998309
Mobile:  +39 333 4963172
Email:   pierangelo.masarati@sys-net.it
---------------------------------------



Up to top level
Build   Contrib   Development   Documentation   Historical   Incoming   Software Bugs   Software Enhancements   Web  

Logged in as guest


The OpenLDAP Issue Tracking System uses a hacked version of JitterBug

______________
© Copyright 2013, OpenLDAP Foundation, info@OpenLDAP.org