Ralf Haferkamp wrote:
Am Donnerstag 02 Oktober 2008 06:26:44 schrieb Howard Chu:
I was dusting off some of the last rfc2307bis revisions Luke sent me, and then remembered how much of a mess we still have with groups. Here are some ideas I'm toying with, would like some feedback before drafting for IETF-LDAPext.
Nice, to see that something is going on in that area. :)
We already know that groupOfUniqueNames is misleading and should be avoided. The big problem with groupOfNames is that member is required. So my first thought was a new groupOfMembers objectclass where member is optional (MAY instead of MUST).
Along the way I was thinking that perhaps a different concept was needed here, like setOfNames instead. The main thinking being: sets implicitly have unique membership sets may be empty sets may be comprised of other sets
This presents a single solution to the whole static/dynamic/nested groups mess: setOfReferences.
The (multivalued of course) "reference" attribute is a URI. if it's in the form of a plain DN, then it is the DN of a single member. if it's in the form of an absolute qualified URI (i.e., it begins with a "ldap:///" spec) then it dereferences the URI to derive the members.
For a nested group, you would use ldap:///cn=foo,o=bar?reference?base
which would join (union) the values of the referenced entry's reference attribute to this set.
One problem with this could be, that would be impossible to find out which nested groups a certain group is a member of. With the direct DN references ("member"-Attribute) that was still possible. If you would allow nested groups in the rfc2307bis revision that might become a problem. Think of e.g. the getgrouplist(), initgroups()s calls.
Note that nss_ldap today already uses nested groups, it simply recursively looks up everything. (And that can be quite expensive right now.) At the very least we should have an immediate way to differentiate simple DNs from nested group references to eliminate unnecessary recursions here.