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

[Andrew Findlay <andrew.findlay@skills-1st.co.uk>]

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.

Andrew
-- 
-----------------------------------------------------------------------
|                 From Andrew Findlay, Skills 1st Ltd                 |
| Consultant in large-scale systems, networks, and directory services |
|     http://www.skills-1st.co.uk/                +44 1628 782565     |
-----------------------------------------------------------------------

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