--On Tuesday, January 16, 2007 7:48 PM +0100 Pierangelo Masarati
<ando(a)sys-net.it> wrote:
> is the ACL in place (admin group comes before this acl with full
read
> to everything in the tree).
The last patch I sent you was not addressing this issue. In this case, I
believe the software is behaving as expected, according to the discussion
in <
http://www.openldap.org/lists/openldap-devel/200701/msg00056.html>.
What the patch should give you, is the capability to compare the "member"
of the dynlist, assuming the identity you use has "compare" privs on the
attributes in the URL's filter. Would this be of help? In any case,
could you try it?
I will try it, but it is not of help.
The problem here, is that we are approaching things from different
viewpoints. In your viewpoint, the user requesting access is or should be
a member of the group, and therefore, really only needs compare to know if
it is or isn't. You've apparently extended that some (?) to allow it to
see if others "compare" to be members of the group.
In my viewpoint, the user requesting access is in no way actually
associated with the group. It is an external application deciding multiple
things. It may (a) be deciding if its users should have access (in which
compare is sufficient), or (b) deciding whether or not to *list* the
membership of the group.
This secondary approach obviously works just fine for static groups, and to
make dynamic groups behave differently means that one cannot depend on
"group" behavior as being consistent, which for me is extremely
problematic, as my applications should not need to "know" whether or not
the group was implemented statically or dynamically. See:
<
http://www.openldap.org/lists/openldap-devel/200701/msg00054.html>
<
http://www.openldap.org/lists/openldap-devel/200701/msg00055.html>
--Quanah
--
Quanah Gibson-Mount
Principal Software Developer
ITS/Shared Application Services
Stanford University
GnuPG Public Key:
http://www.stanford.edu/~quanah/pgp.html