RE: (ITS#4760) problem with group caching and proxyAuth control

[richter@ecos.de]

> 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 **