[EMAIL PROTECTED] wrote:
Update of /repo/OpenLDAP/pkg/ldap/servers/slapd/overlays
Modified Files:
dyngroup.c 1.13 - 1.14
Log Message:
Add cn=config support
I thought this was going to be replaced by dynlist, whose functionality
it provides a subset. Note that in HEAD dynlist can
Pierangelo Masarati wrote:
[EMAIL PROTECTED] wrote:
Update of /repo/OpenLDAP/pkg/ldap/servers/slapd/overlays
Modified Files:
dyngroup.c 1.13 - 1.14
Log Message:
Add cn=config support
I thought this was going to be replaced by dynlist, whose functionality
it provides a subset.
Howard Chu wrote:
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
Pierangelo Masarati wrote:
Howard Chu wrote:
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
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
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
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
Russ Allbery wrote:
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
Howard Chu wrote:
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
