[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: commit: ldap/servers/slapd/overlays dyngroup.c
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
---------------------------------------