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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] ---------------------------------------