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

[simo <idra@samba.org>]

On Wed, 2007-09-19 at 11:48 -0700, Howard Chu wrote:
> simo wrote:
> > 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.
> 
> As usual, garbage-in-garbage-out. You can probably implement enforcement in 
> the server, but that doesn't need to be mandated in the specification. There 
> are plenty of standards track schema elements that use a very general syntax, 
> but whose description says a value of a particular form is expected.
> 
> Also, even if the server doesn't enforce the semantics, the end result is a 
> benign failure. I.e., if someone puts the DN of a groupOfEntries into the 
> member attribute of a group, the worst that can happen is that those group 
> members will not get the privilege that group membership was intended to 
> convey. You cannot introduce a security breach here by accidentally giving 
> privilege to a larger member set than intended. Likewise, the worst that can 
> happen by putting the DN of a non-group entry into a nestedGroup attribute is 
> that that specific user will not have his intended privilege.
> 
> On the other hand, by throwing everything together into a single member 
> attribute, you can accidentally nest groups together and there is no obvious 
> audit trail that will highlight your mistake. Compartmentalization here is a 
> good thing, from a security standpoint.

While I agree with the general concept, I don't with the specific
example. If you accidentally put a group into the member attribute you
can as well put it accidentally into the nestedGroup one as well.
I don't see why one should me more probable than the other.

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