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.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.
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?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.
+1 I think that's a good plan.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@lists.fedoraproject.org To unsubscribe send an email to 389-devel-leave@lists.fedoraproject.org_______________________________________________ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-leave@lists.fedoraproject.org
_______________________________________________ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-leave@lists.fedoraproject.org