Full_Name: Christopher Klinge
Version: 2.4.44
OS: Debian
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (93.193.142.51)
As of right now, dynlist can be used to expand one level of nesting:
overlay dynlist
dynlist-attrset parentGroup childGroup
dn: cn=Parent Group,ou=Groups,dc=example,dc=com
objectClass: parentGroup
cn: Parent Group
childGroupURL: ldap:///cn=Child
Group,ou=Groups,dc=example,dc=com?member?sub?
dn: cn=Child Group,ou=Groups,dc=example,dc=com
objectClass: childGroup
cn: Child Group
member: cn=User A,ou=People,dc=example,dc=com
member: cn=User B,ou=People,dc=example,dc=com
member: cn=User B,ou=People,dc=example,dc=com
Querying the parent group will return:
dn: cn=Parent Group,ou=Groups,dc=example,dc=com
objectClass: parentGroup
cn: Parent Group
childGroupURL: ldap:///cn=Child
Group,ou=Groups,dc=example,dc=com?member?sub?
member: cn=User A,ou=People,dc=example,dc=com
member: cn=User B,ou=People,dc=example,dc=com
member: cn=User C,ou=People,dc=example,dc=com
If cn=Child Group were to be a parent group itself, no further expansion would
take place.
I propose enabling dynlist recursion and adding a new configuration directive:
dynlist-rec-attrset <group-oc> [<URI>] <URL-ad> <rec-ad>
[[<mapped-ad>:]<member-ad>]
Except for rec-ad, all parameters behave exactly like those of dynlist-attrset.
The attribute rec-ad is mandatory. It is a comma separated list of attributes
for which dynlist recursion is enabled.
By adding a new directive, backwards compatibility is guaranteed.
I suggest using a depth counter to prevent infinite loops. A configurable
threshold with a fairly small default value is both light weight and
sufficiently rigorous. Logging a suitable warning message upon reaching the
threshold would inform the administrator about possible loops.
