Re: groups, rfc

[Ralf Haferkamp <rhafer@suse.de>]

Am Donnerstag 02 Oktober 2008 10:20:10 schrieb Howard Chu:
> 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.)
Yes, I know. But was wondering how exactly one could make reverse lookups 
(what (nested) groups is userX member of) working with the above schema. Those 
lookups would be needed by the above mentioned NSS functions.

> At the
> very least we should have an immediate way to differentiate simple DNs from
> nested group references to eliminate unnecessary recursions here.
Yes, that would of course be helpful. The most obvious approach would be to  
introduce differnt types of "reference" Attributes. E.g. "dnReference" for 
"normal" groupsmembers, "nestedDnReference" of nested members and 
"uriReference" of dynamic members. As I guess you have already thought about 
such an approach, what are the disadvantages of those?

-- 
regards,
	Ralf