[Date Prev][Date Next] [Chronological] [Thread] [Top]

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

Gerald Richter wrote:
>> 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)
OK, I see.  In my test ACLs for authzTo didn't make use of groups.  It 
makes sense to clear out identity related cached stuff when the identity 
changes.  What I'm looking for is a __simple__ test that exploits the 
feature.  This would allow to clearly spot the issue in the first place, 
and prepare a regression test.  I'll do some more testing.


Ing. Pierangelo Masarati
OpenLDAP Core Team

SysNet s.n.c.
Via Dossi, 8 - 27100 Pavia - ITALIA
Office:   +39.02.23998309
Mobile:   +39.333.4963172
Email:    pierangelo.masarati@sys-net.it