--On Tuesday, January 16, 2007 7:48 PM +0100 Pierangelo Masarati ando@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