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