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

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/