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

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

Howard Chu wrote:
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).

It seems we're both talking about two different use cases.

In a typical dyngroup usage, the DNs of entries matching the URL are the only piece of information collected. For dynlist, you actually merge multiple attributes from the matching entries into the result. I agree that using a dgIdentity here may pose a risk, leaking out data that was not intended.

But again, this is presumably the reason that you created this dynamic object, assigned a dgIdentity to it, and gave read access on it. If that was not the intended purpose, then someone went to an awful lot of trouble to shoot themselves in the foot.
-- 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/