Re: commit: ldap/servers/slapd/overlays dyngroup.c

[Howard Chu <hyc@symas.com>]

Pierangelo Masarati wrote:
> Howard Chu wrote:
>
> > > A dgPolicy flag could determine what behavior, in case of no compliance
> > > with policy, should be taken: either (a) or (b), or none.
> > dgAuthz seems like overkill. If the user has read/search privs on the
> > group entry, that ought to be sufficient.
>
> I disagree: by running an internal operation with dgIdentity, and
> returning the results of that operation, you'd break the security model
> of OpenLDAP.  In fact, a dynamic group can unveal data that would
> otherwise be inaccessible to a user.  In fact, only running the search
> with the user's identity guarantees the security model is not broken,
> but dgAuthz, at least, gives some granularity.  This doesn't break
> either backwards compatibility nor draft-haripriya-dynamicgroup: those
> who want to stick with it only have to ignore dgAuthz.

If I create a group and give a user access to read the "member" attribute of 
that group, then I wanted them to be able to read that attribute, period. I 
don't care how the contents of that member attribute got populated.

If there is something in there that a particular user should not know about, 
then they simply should not have access to the entry/attribute in the first place.

As far as security goes, I think it is far more important that dyngroups behave 
*consistently*, such that when they are used in ACLs, they always return a 
predictable result. I.e., a static group yields the same information no matter 
how it is used or who is using it. A dyngroup should do the same (given that 
its constituent data remains unchanged).
--
  -- 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/