[Date Prev][Date Next] [Chronological] [Thread] [Top]

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



On Wed, 2007-09-19 at 19:01 +0100, Andrew Findlay wrote:
> On Wed, Sep 19, 2007 at 01:07:13PM -0400, Liben, Michael (GTI) wrote:
> 
> > This anticipates a reliable mechanism that ensures direct members
> > are not added to the nestedGroups attribute and that nested groups are
> > not inadvertently added to the member attribute.
> 
> I don't think there needs to be any server-side control on that. There
> are many cases in LDAP where the protocol and schema allow the client
> to do 'silly' things. If we try to tie things down too hard there is
> no room for flexibility. A designer can choose to use ACLs or
> structure definitions to apply some measure of control, or can rely on
> 'business logic' in the update process to do so.

The problem is that you have a generic "DN" container that is given
specific semanthics. IE nestedGroupObject is supposed to contain only
entries that have groupOfEntries as its STRUCTURAL class, but you do not
enforce it. So it may contain anything. Same for member.

This just means clients have to cope with bad entries.

I think that the problem is caused by artificial separation of members
in 2 classes.

> > How would the server respond if an object is included in both attributes?
> 
> OK, suppose we have a group A containing nestedGroup B and members B
> and C.  B is itself a group containing members D and E.
> 
> If server-side nesting/expansion is *not* requested then there is no
> issue: it is up the client to interpret the data (though it would be
> good to define the algorithm so that client and server get the same
> results!).
> 
> If server-side support *is* requested, then:
> 
> Group expansion of A results in a list of member attributes:
> 	B C D E
> 
> It so happens that one of those DNs is a group. The others could be
> anything. I see no problem here.
> 
> Now, if C is added to group B as a member, the expansion will find C
> twice. The server should suppress the duplicate.

The server will always have to suppress duplicates, this is not a
problem.

You will have the same in this perfectly legit scenario:

Group A contains Group B and Group C
Group B has users a, b, c
Group C has users a, d, e

Also another thing servers and clients MUST be aware is that this may
introduce recursion problems

Group A -memberof-> Group B -memberof-> Group A -repeat ad nauseam-|

Nested groups have advantages and issues, but that's not what we are
discussing, we are discussing whether splitting membership in 2
attributes by type is good or not, AFAICT.

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