[GEODE-7283] OQL Method Authorizer in Query Execution Context

• Type: Improvement
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Fix Version/s: 1.11.0
• Component/s: querying
• Labels: GeodeCommons
• Assignee: Juan Ramos
• Reporter: Juan Ramos
• Created: 09/Oct/19 12:41
• Updated: 30/Dec/19 18:49
• Resolved: 25/Oct/19 16:37

Description

When using security, the OQL method authorizer is instantiated multiple times during the OQL execuion, incurring into a waste of time and resources.
The authorizer is obtained through the queryContext.getCache().getQueryService().getMethodInvocationAuthorizer() method, which basically creates a new instance of the DefaultQueryService and, also, a new instance of the MethodInvocationAuthorizer configured:

DefaultQueryService.java

public DefaultQueryService(InternalCache cache) {
  if (cache == null)
      throw new IllegalArgumentException("cache must not be null");

  this.cache = cache;
  if (!cache.getSecurityService().isIntegratedSecurity() || ALLOW_UNTRUSTED_METHOD_INVOCATION) {
    // A no-op authorizer, allow method invocation
    this.methodInvocationAuthorizer = ((Method m, Object t) -> true);
  } else {
    this.methodInvocationAuthorizer = new RestrictedMethodAuthorizer(cache);
  }
}

When using implicit method invocation, the above implies that the authorizer will be created X times per query, being X the amount of attributes accessed per object multiplied by the amount of objects traversed by the query. As an example, if we have a region with 100 entries (entry has a non-public name attribute with a public getName() accessor) and we execute SELECT o.name FROM /Region o, the MethodInvocationAuthorizer will be instantiated 100 times.
When using explicit method invocation things are "better": the MethodInvocationAuthorizer is only created once for every new (unknown) method during the lifetime of the Geode member, and that's basically because the MethodDispatch class is internally cached and it also has the MethodInvocationAuthorizer used when it was created stored internally. This incurs into another problem: once a MethodDispatch is created, the MethodInvocationAuthorizer can't be changed, the user needs to restart the member in order to clear the cache (CompiledOperation) and force the query engine to execute a new lookup of the now unknown method (which must also be done through the API when implementing GEODE-6991, otherwise changes won't be applied).
The MethodInvocationAuthorizer should be unique and unchangeable during the execution of a particular query on a particular member, so we should investigate whether it would make sense to create it only once at the beginning of the query execution and have it directly available as part of the QueryExecutionContext.

Issue Links

• blocks: GEODE-7351 Verify constraints when changing the MethodInvocationAuthorizer
• is a child of: GEODE-6983 Epic for OQL Method Invocation Security
• links to: GitHub Pull Request #4179