On Mon, 2017-02-27 at 17:51 -0800, Noriko Hosoi wrote: > 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. Well, this could be the case, but the logic still stands when you think about the process, and how we get entries from the backend and do the aci checks .... > >>> 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? This was a generic template, for a specific op, we can still do this. If you look at ldbm_add.c, the acl check takes the pblock with mods, the entry, etc. So really, this still works, because in the do_add for example, we have the mods in the pb, and then we just step through the entry retrival and check. > > 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. Yeah, it's just the specifics of how we achieve it. This idea of a local vs remote flag could even perhaps be an "ACL check flag", and we have others as needed. That way we can start to clean up our logic a bit. The do_<op> functions are really large and so I think this would help to break up the steps nicely, same with the ldbm_<op> functions. > > > >>> 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 -- 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
