[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: groups, rfc

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

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.
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/