[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.
p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.n.c.
Via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
------------------------------------------
Office: +39.02.23998309
Mobile: +39.333.4963172
Email: pierangelo.masarati@sys-net.it
------------------------------------------