> I'm not sure I understand the issue you describe. In
fact,
> groups appear to be cached on a per-operation basis,
and user
> membership is evaluated using the authorized identity
(B in
> your case), so the behavior should be correct. I've
made a
> simple check using re23 and things appear to work as
> expected: I log in as a user (A) that is not in a group
and
> authorize as a user (B) that is in that group. I
previously
> configured slapd so that only members of that group are
> allowed to read an attribute in the whole db (say
"cn").
> Things work as expected: if I login as user A I can't
see
> "cn", but if I either log in as user B, or
login as user A
> and proxyAuthz as B I can read the "cn". Can
you provide a
> simple example (slapd.conf, db.ldif and sequence of
> operations, e.g. in a shell script) that causes the
issue you see?
>
I think the point is that the group must be evaluated
already in the search
for the AuthzTo attribute.
So my User A has the AuthzTo attribute set to User B and I
have the
following access control:
access to *
by
group/accessCTRL/uniqueMember="cn=Admins,dc=testuml,dc=
test"
write
by * break
...
access to * attrs=authzTo
by self read
by * break
...
User A is not member of cn=Admins,dc=testuml,dc=test, but
user B is. So when
I log in as user A and proxyAuth to Openldap will evaluate
the group
membership for A and cache it, during the search for the ACL
to authzTo. A
is not member.
Now when the actual search operation takes places, openldap
will used the
cached result (which was "is not member"), which
is wrong because the user
has changed since the group membership was cached.
I hope this makes the problem more clear (I have a test
environment here,
but it is very complex and easy transferable)
Gerald
** Virus checked by BB-5000 Mailfilter **
|