Howard Chu wrote:
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.
I'll check.
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.
Well, you'd kill two birds with one stone ;)
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.
As I commented on ldapext@ietf.org on that draft, I think we should rather enhance that concept by providing granular access policies. For example:
a) absent dgIdentity: search with user's identity b) empty dgIdentity: search anonymously c) present dgIdentity: search with dgIdentity; but: if dgAuthz is present, check that user's identity complies with that policy (much like idassert-authzFrom, with 1.3.6.1.4.1.4203.666.2.7 OpenLDAP authz syntax.
A dgPolicy flag could determine what behavior, in case of no compliance with policy, should be taken: either (a) or (b), or none.
I don't think the original Author was fine with my remarks, so we should just take our own path, and perhaps re-define dgIdentity, to clearly depart from that (broken, IMHO) draft.
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it ---------------------------------------