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

[simo <idra@samba.org>]

On Wed, 2007-09-19 at 18:32 +0100, Andrew Findlay wrote:
> On Wed, Sep 19, 2007 at 12:42:12PM -0400, simo wrote:
> 
> > The algorithm complexity is the same, although, it is true, a client may
> > require more operations.
> > 
> > Actually I think this problem would be better solved by a control to ask
> > the server to do the calculations for us (and IIRC there is a control
> > like that in the AD implementation called ASQ or something like that)
> > and use a cache, so we have both an efficient way to do it and avoid the
> > artificial distinction.
> 
> Server support would certainly be valuable in many cases and a control
> sounds like a good way to ask for it. However, I think that is
> orthogonal to the question of whether there should be two attributes.
> 
> Consider the case of a group giving access to some resource. As the
> owner of the resource I have control of the group, so I can give user
> X access to it by putting the DN of X's entry into the group as a
> member. I might also control another group called Q whose members
> should have access to the resource so I add that too. So far so good,
> but if there is no distinction between leaf members and nested groups
> *in the group entry itself* it would be possible for user X to give
> access to my resource to other people by adding member attributes to
> his own entry. As the resource owner I would not want that to be
> possible. This alone seems like a good reason not to allow nesting via
> the 'member' attribute.

This is an interesting view, but clashes with the fact that
groupOfEntries is defined STRUCTURAL, so it is not possible for a user
to add this class to its own object (and even if it were possible you
imply that user X has access to his own entry which is usually not true)
and therefore not possible to add members.

If you agree I'd say this is a non issue and would not consider it in
the debate.

> > > > 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 ?
> > > 
> > > I am not sure that I understand your point there. Remember that
> > > groupOfEntries is a STRUCTURAL class, so it cannot be added to an
> > > existing entry or removed from one.
> > 
> > AHHH Right, that was the other thing in the back of my mind that kept
> > bogging me, but I forgot to post about it.
> > 
> > STRUCTURAL classes are often annoying and I think they should be used
> > only when the object is meant to be incompatible with other ones and/or
> > embed a unique new concept that should make it naturally incompatible
> > with other objectClasses.
> > 
> > What is the reasoning for it being STRUCTURAL here?
> 
> I also avoid structural classes where possible. In this case it seems
> reasonable though. A group is a fairly basic concept and if it did not
> have a structural class of it own then group objects would have to be
> based on something else. The closest I can think of is
> organizationalUnit, but that is not really a good model for the common
> uses of groups to control authorisation.
> 
> A further reason for it being structural is that groupOfNames is
> structural. If groupOfEntries is to replace it then this should not
> change.

Make sense, I was interested in the reason, and actually the scenario
above is more a reason for keeping groupOfNames structural than a reason
to keep 2 separate attributes.

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