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

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

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.

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.

--
  -- Howard Chu
  Chief Architect, Symas Corp.  http://www.symas.com
  Director, Highland Sun        http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP     http://www.openldap.org/project/

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