Quanah Gibson-Mount wrote:
--On January 16, 2007 6:34:39 PM +0100 Pierangelo Masarati
<ando(a)sys-net.it> wrote:
> Quanah Gibson-Mount wrote:
>
>> This patch also does not work, continuing to use the credentials of the
>> bound user.
>
>
> What operation are you performing when it gets to evaluate that filter?
> Can you describe it a little bit further?
ldapsearch -LLL -Q -h ldap-dev1 -b
"cn=groups,cn=applications,dc=stanford,dc=edu" cn=registry-consult
Output is:
dn: cn=registry-consult,cn=groups,cn=applications,dc=stanford,dc=edu
objectClass: groupOfURLs
cn: registry-consult
memberURL:
ldap:///cn=people,dc=stanford,dc=edu??sub?(suprivilegegroup=registr
y:consult)
(but no members). Searching with my admin credentials, I get a full
user list.
access to
dn.exact="cn=registry-consult,cn=groups,cn=applications,dc=stanford,dc=edu"
by dn.base="uid=cadabra,cn=accounts,dc=stanford,dc=edu"
sasl_ssf=56 read
by * none
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?
p.