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

["Jong-Hyuk" <jongchoi@OpenLDAP.org>]

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 search
spec but requested by distinct identities. From the next search, the request
will be satisfied by the internal database if they are answerable. Unless we
have the same access control in the proxy cache as in the remote server, a
search  can return entries originally prohibited by the target server. I
also suspect that proxyAuthz is required for the proxy cache when it needs
to deal with clients having different access control.
- Jong-Hyuk

----- Original Message ----- 
From: "Pierangelo Masarati" <ando@sys-net.it>
To: "Jong-Hyuk" <jongchoi@OpenLDAP.org>
Cc: "Howard Chu" <hyc@symas.com>; "OpenLDAP Commit"
<openldap-commit2devel@OpenLDAP.org>
Sent: Monday, July 12, 2004 5:11 PM
Subject: Re: commit: ldap/servers/slapd/overlays pcache.c


> 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
>
>
>