[Date Prev][Date Next]
Re: commit: ldap/servers/slapd/overlays pcache.c
> > I think that the access control aspect of the proxy cache in relation to
> > back-ldap needs to be elaborated further. Suppose a situation where the
> > proxy cache stores search entries from the searches having the same
> > spec but requested by distinct identities. From the next search, the
> > request
> > will be satisfied by the internal database if they are answerable.
> > we
> > have the same access control in the proxy cache as in the remote server,
> > search can return entries originally prohibited by the target server. I
> > also suspect that proxyAuthz is required for the proxy cache when it
> > to deal with clients having different access control.
> What you're depicting is a scenario where the cached search is done by the
> proxy with some special identity that ensures a broad access, and
> subsequent operations on the cached data are performed locally based on
> the client's identity by means of the local access control rules. This is
> a very specific scenario that implies a trust relation ship between the
> remote server and the proxy, so that the remote server is willing to give
> broad access to the proxy itself and delegate access control to the proxy.
> In this case, the cahced request is performed with an administrative
> identity. I see other possibilities:
> a) remote requests are performed by the proxy under an administrative
> identity, cached once for all and then satisfied locally based on the
> client's identity by locally applying acces rules.
> b) remote requests are performed with the client's identity (either by
> binding as the client or by asserting its identity), and cached on a
> per-client basis; access control is directly applied by the remote server,
> and for a client only data it can access is cached.
> On the one hand, the latter approach may lead to a proliferation of the
> cached data, but it does not require the remote server to trust the proxy
> and delegate access control. From my understanding, this latter was the
> approach of proxycache, at least before it made it into an overlay. Note
> that I'm not favoring any of the approaches (there might even be more,
> with overlappings); they're both reasonable, and may apply to specific
(b) can be viewed as the current method by and large but there're
- It is not crystal clear what you meant by the caching on a
per-client basis, but it seems to me that the pcache caching
is not performed on a per-client basis.
- Hence, if multiple clients having different access controls
accessed the remote target server, the proxy cache will cache
their aggregate result. Without the same access control set up
at the proxy cache, a client can access data in the proxy cache
which are not allowed in the remote target server.
(a) can be in fact viewed as a replica-initiated replication.