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.