Re: [ldapext] Nested group (was: groupOfEntries object class proposal)

[simo <idra@samba.org>]

On Wed, 2007-09-19 at 11:46 +0100, Andrew Findlay wrote:
> On Wed, Sep 19, 2007 at 09:35:41AM +1000, Steven Legg wrote:
> 
> > The advantage of *not* having nested groups is that it is sufficient
> > to just read the values of the member attribute to determine group
> > membership. If there are nested groups, then it is necessary to
> > read each of the entries named in the values of the member attribute
> > to see which of them, if any, are themselves groups. That could be
> > a big performance hit for a group with a large set of members.
> 
> Good point. Servers have more options here, but a client dealing with
> nested groups has to do a silly amount of work.

No, its not a good point, as that happens only if the designer of the
directory decides to use this feature.
If he so decides, he knows the limits and the problems he goes on doing
that and it is his responsibility.

Let's not try to be smarter than necessary, a schema should not be used
to enforce a way to do things.

> > If nested groups are to be allowed, then I would rather see the
> > nested groups listed in a separate attribute, e.g., called nestedGroups,
> > so that implementations only need to read the entries that really
> > are nested groups.
> 
> That would be a great improvement in efficiency. There would also need
> to be an auxiliary object class to identify groups that might contain
> such attributes - nestedGroupObject or perhaps groupOfGroups.
> (Or the groupOfEntries class could permit the nestedGroup attribute as
> well as the member attribute. I think I would prefer a separate
> class.)

I really don't see any value in using a different attribute.
An apple is always an apple even if you call it orange. If that
attribute is present, the client has to do all the work anyway.
The only difference is that you have to use a more complex filter to
show the members of a group and probably also 2 indexes instead of just
one.

> On Wed, Sep 19, 2007 at 09:48:14AM +1000, Luke Howard wrote:
> 
> > This is what Novell did with eDirectory (they also have an option where 
> > nested members are presented as values of member).

Which is bad because at that point the client have no way to tell which
group exactly a user is member of. It is good only for simple
authorization schemes (and was probably done to keep old unix clients
happy).

> It is certainly more efficient if the server is prepared to do things
> like that, but it does require new code so it is less likely to
> implemented by all servers. There is also the question of how to
> manage such an entry as the client clearly cannot read the member
> attributes and send updates based on what it sees.

exactly, it is just a hack, necessary in some cases, but just an hack.

> > AD and rfc2307bis, however, simply have groups listed a values of 
> > member; the client is responsible for dereferencing and transiting if 
> > required.
> 
> There are enough performance problems with LDAP NIS group methods
> already! Adding client-side nested groups can only make it worse...

It's up to you to use nested groups or not. It's not mandatory, and
doing it client side has also benefits.

Suppose I need to check user A is in group A, where group A has 128 sub
groups, with others again.
Now if you do server side resolution at each query of the member
attribute you have to fully unwind all groups every time (sure caching
helps), instead if you are a client, you can stop at the first group you
find containing the user (in case it is group A it is much more
convenient). Also, clients smart enough to understand nested groups, can
probably be smart enough to do some smart caching, and beating the
server a lot less often.

> On Wed, Sep 19, 2007 at 11:34:22AM +0200, Michael StrÃder wrote:
> 
> > I fully agree. One really has to think twice whether nested groups are
> > really needed in a particular use-case and worth the performance hit.
> > 
> > > If nested groups are to be allowed, then I would rather see the
> > > nested groups listed in a separate attribute, e.g., called nestedGroups,
> > > so that implementations only need to read the entries that really
> > > are nested groups.
> > 
> > +1
> 
> It looks as if the nested groups issue needs tackling. Should I expand
> this I-D to include it? The consensus seems to be:

FWIW I think your original proposal is much simpler, and lets architects
decide what to do without artificial separations of members depending on
the fact they are groups or users.

Also it is more consistent, what if I have an Entry object listed as
emmebr in another that lately is added a groupOfEntries objectclass to?
Should the server go around all other groupOfEntries objects in search
for members to be changed to nestedGroupObject ?

Keeping it just a member make this a non-issue from the consistency PoV.

> 1)	groupOfEntries member attributes should not point to groups
> 	whose members are to be considered part of the group being
> 	described.
> 	
> 	I see no problem with allowing them to point to groups if
> 	expansion/nesting/inclusion is not required.

I see no problem, full stop. It's the architect responsibility to find
the right trade-off .

> 
> 2)	There should be a new aux class and attribute to support
> 	client-side group nesting.
> 
> 	Servers can support group nesting in more efficient ways and
> 	some of them already do. Should there be an attempt to
> 	standardise the schema that supports this?

IMHO no.

Simo.

-- 
Simo Sorce
Samba Team GPL Compliance Officer
email: idra@samba.org
http://samba.org


_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext