On Mon, 2017-02-27 at 12:23 -0800, Noriko Hosoi wrote:
> Hi William,
>
> A couple of questions (as usual... :)
>
> On 02/26/2017 03:51 PM, William Brown wrote:
> > Hi,
> >
> > I think that we should have a flag of a backend as local or remote for
> > DS.
> Does the remote backend mean the referral and/or the chaining backend?
> Or could there be more?
At the moment I only meant referral and chaining are "remote". LDBM is
local.
> > The reason for this is to move the ACI chechk outside of LDBM into
> > do_<op>() but only for local backends.
> The outside means pre- backend or post- backend or both?
>
> If ACI contains attribute value, how it'd be taken care of?
That is a good question.
Right now we perform the acl checks in ldbm_<op>.c, generally before we
call any pre operation plugins. Before this, the backend retrieves the
entry from the cache as needed.
I'm suggesting that instead of keeping all this logic in ldbm, we
separate it up so that in rough pseudo code:
do_<op>
if local_be:
e = be_get_entry()
plugin_call_acl_plugin(e, op, ...)
plugin_call_plugins(e, ...)
be_commit_<op>(e, mods ....)
else:
forward_remote_operation
The idea is that we can seperate the operation logic of the server
( plugin calls, acl checks) from the backend. Right now, LDBM is really
tied into how an operation flows and operates, and it shouldn't be
involved at all. LDBM should be responsible for a cache, and how entries
are on disk, how we apply filters and indexes to that.
Where as the server outside should direct plugin operations, access
control and others.
Think about if we want to implement another backend type: Well we would
have to duplicate all these calls to plugin hooks, acls, etc, and they
may be out of order, or introduce other subtle issues.
So having the local vs remote flag, really allows us to start to unpick
this, because we can make the checks happen in the do_<op> component -
This means implementing a new backend will be easier for us in the
future, and we can confine our server logic to one place.
> > This way when we support multiple local backend types (which we do
> > already with fedse etc), instead of each backend suppling the need to
> > call acl's, we can do it once in the do_<op> at the correct step.
> >
> > We don't need this for remote backends as we can not guarantee we parse
> > the ACI and that adds extra complexity to the situation. We assume the
> > remote backend does the ACI check for us via some kind of passthrough
> > bind, or other means.
> >
> > Additionally, this flag would allow other plugins to distinguish if they
> > should operate or not on the operation - We may not want to apply
> > memberof to a remote BE for example.
> >
> >
> >
> > _______________________________________________
> > 389-devel mailing list -- 389-devel@xxxxxxxxxxxxxxxxxxxxxxx
> > To unsubscribe send an email to 389-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
>
>
> _______________________________________________
> 389-devel mailing list -- 389-devel@xxxxxxxxxxxxxxxxxxxxxxx
> To unsubscribe send an email to 389-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
--
Sincerely,
William Brown
Software Engineer
Red Hat, Australia/Brisbane
Attachment:
signature.asc
Description: This is a digitally signed message part
_______________________________________________ 389-devel mailing list -- 389-devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to 389-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
