Re: commit: ldap/servers/slapd/overlays pcache.c

["Pierangelo Masarati" <ando@sys-net.it>]

I haven't checked the proxy cache code that much, but I thought that the
internal database was used only as a bulk storage, and the access control
on returned data was performed by the frontend based on the back-ldap
database access rules, if any.  Note that the cached stuff, in typical
applications, only contains those results the remote server is willing to
unveal to the user who requested it via back-ldap, and the proxy is not
applying any access rules.  If this is not the case, of course we need the
cache database to inherit the access rules of the proxy.

p.

>> Pierangelo Masarati wrote:
>>
>> >>>>Also, is it okay not to call acl_append() when non-NULL be is given
>> to
>> >>>>backend_startup() ?
>> >>>
>> >>>I guess it is.  As long as backend_startup() is called with NULL when
>> >>>all
>> >>>the -regular- databases exist, global ACLs get appended to database
>> >>>specific ones.  The only case of backend_startup() called for a
> specific
>> >>>database should be that of special purpose, internal databases like
>> >>>pcache, so they should not need ACLs.  In any case I wonder if it
>> would
>> >>>be
>> >>
>> >>The internal databases can be used with non-root user although it's
>> not
>> >>likely.
>> >
>> >
>> > I mean: if a database is defined as internal, i.e. it does not belong
>> to
>> > the regular database structure, it is very likely that it is used only
> by
>> > those who created it (e.g. proxy cache); of course, if one needs to
> create
>> > a database that is directly visible to regular users, there might be
>> > access control issues.  In that case, the creator of the database
>> should
>> > take care of it, or try to make the internal database fit into the
>> > standard, front-end managed infrastructure.
>> >
>> >
>> >>>the case to split backend_startup() in
>> backendInfo_startup(BackendInfo
>> >>>*)
>> >>>and backendDB_startup(BackendDB *) and call each of them from insid
>> >>>backend_startup(void) for all regular backends first and for all
> regular
>> >>>databases then.  This way, we would have the possibility to startup
> each
>> >>>special or internal database that we add, and we could even add
> backends
>> >>>and start them up separately.
>>
>> I've added a backend_startup_one() to condense some of this code. Some
>> more refinement may be nice. But I agree, the creator of the internal
>> database ought to control what other features it needs.
>
> Hmm... in the proxy cache case, the desired behavior would be to inherit
> the
> features of the original backend, back-ldap. In fact, a copy is performed
> in
> proxy_cache_init() { ... cm->db = *be; ... }, but this is done before the
> features are initialized in backend_startup(). Hence, an apparently better
> solution is to move the copy into proxy_cache_open(). This applies to
> be_acl, be_pending_csn_list, and be_context_csn. The access control of the
> proxy cache internal database should be set to that of back-ldap, because
> the internal database is accessed by the requesting user when the query is
> answerable. The current code seems to apply the access control of the
> internal database which is incorrect.
> - Jong-Hyuk
>
>


-- 
Pierangelo Masarati
mailto:pierangelo.masarati@sys-net.it


    SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497