> I thought this was going to be replaced by dynlist, whose > functionality it provides a subset. Note that in HEAD dynlist can > also be instantiated under the name "dyngroup" (see obsolete names), > with the same configuration syntax. Hm, the last I remember we had agreed that dyngroup should continue to be used, since dynlist does a lot more than dyngroup needed. Did I miss something?

I just went back and re-read ITS#3756. If dyngroup functionality is working fine in dynlist now, then we should just cvs rm dyngroup and drop it from 2.4.

In the meantime, I need to add support for dgIdentity to something. At this point I guess that means I'll add it to dynlist.

It seems to me that we have 3 possible behaviors when the dgIdentity attribute is not present: 1) search anonymously, as suggested in the Haripriya draft 2) search as the current user, as currently implemented 3) search as "self" i.e. the group DN I'm thinking of adding a keyword to select this behavior. This would be a single option that affects the entire overlay, not on a per-attrset basis.

> 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.

So, that behavior of letting the dynlist or dyngroup overlay do a query that the user querying the group tree is not themselves permitted to make is exactly what we need, since we can then use the more granular access control possible on the separate group dns to implement control over entitlement visibility that's otherwise annoying to represent.

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).