Re: commit: ldap/servers/slapd/overlays dyngroup.c
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/