Re: Discuss: local vs remote be flag

[Noriko Hosoi <nhosoi@xxxxxxxxxx>]

Thank you, William!

On 02/27/2017 03:35 PM, William Brown wrote:

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. 

Ok...  I thought the chaining backend could be tricky. :)  For instance, the frontend server could have all the ACIs not just for the local backend as well as for the chained backend servers...  If that's the case, as long as the entry exists, the acl could be handled locally, but maybe that's not the main issue at all for now... :p  So, please never mind.

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. 

How about evaluating the ACLs for the changes made by the operation?  be_get_entry returns the entry on which operation is already done?  (Unless being add, moved, renamed, you may not be able to check the ACL?)  Isn't it sometimes quite expensive?

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.

+1  I think that's a good plan.

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

_______________________________________________
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