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

[simo <idra@samba.org>]

On Wed, 2007-09-19 at 19:43 +0100, Andrew Findlay wrote:
> On Wed, Sep 19, 2007 at 02:08:35PM -0400, simo wrote:
> 
> > > 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.
> 
> That depends on whether the expansion rule incudes a check on the
> objectclass of the nested groups. I was expecting it to work with any
> entry that contains member attributes, in order to allow for a mix of
> groupOfEntries and other group-like things that have been given an aux
> class to permit members (e.g. organizationalUnit might sometimes get
> this).
> 
> Perhaps my example was not general enough anyway. Maybe user X is in
> some part of the tree controlled by different administrators. I am
> prepared to grant access to my resource to that one user, but I dont
> want one of 'their' admins replacing the user entry with a group that
> gets expanded. This is like X.509 certificate authorities: they will
> give you a cert for your own ID but not one that allows you to certify
> others. We are talking about control and trust here, and trust is not
> always transitive.

Sorry but I see a fault here as well.
Once you add, as a member, a user controlled by a foreign entity your
security is already screwed if you don't trust that entity.
If you trust it then you trust they will not try to use their power to
exploit your system.
That said, this example makes much more sense.

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