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

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

richter@ecos.de wrote:
> I noticed that when I use the proxyAuth control group members are not correctly
> resolved.
> What I do is to login as user A and do a search with proxyAuth control with an
> authzid of user B.
> User B is member of a group, which grants him access to the some items. User A
> is not.
> When directly logging in as user B, everything is ok. Using proxyAuth user B
> doesn't have access to the items that are granted to the group.
> The reason is that the group membership is cached, and therefore users A
> membership is used for ACL evaluation, instead of users B membership.
> The attached patch, simply deletes all cached groups, when inside the proxyAuth
> control setup, which resolvs this issue.
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?


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