THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
RestrictedMethodAuthorizerGeodeMethodAuthorizerUnrestrictedMethodAuthorizerRegExMethodAuthorizerJavaBeanAccessorMethodAuthorizer
The RestrictedMethodAuthorizer will be the authorizer used by default out of the box, as it contains the list of methods per object type that are currently considered safe and it also prevents any possible re-introduction of CVE-2017-9795.
The GeodeMethodAuthorizer will The UnrestrictedMethodAuthorizer will basically allow any method execution as long as the target object does not belong to a Geode package or, if it does belong to a geode package, it's considered safe (sub-set of methods already allowed by the RestrictedMethodAuthorizer). The other two authorizers will always delegate to RestrictedMethodAuthorizer and expand the set of allowed methods with whatever the internal implementation is configured to do. The JavaBeanAccessorMethodAuthorizer covers the most common use cases and requires little to no configuration effort. For those use cases not covered, the users can choose to use the RegExMethodAuthorizer, which allows them to configure which methods to allow directly through regex expressions. If none of the above is a good fit for a particular situation, the user ultimately has the option to provide its own implementation of the MethodInvocationAuthorizer interface and do whatever needed in order to allow/deny the execution of particular methods.
...
| Authorizer \ Threat | Reflection | Cache Access | Region Access | Entry Modification |
|---|---|---|---|---|
| RestrictedMethodAuthorizer |  | | | |
| GeodeMethodAuthorizerUnrestrictedMethodAuthorizer | | | |  |
| RegExMethodAuthorizer | | | | |
| JavaBeanAccessorMethodAuthorizer | | | | |
...
- Too restrictive
. - User can't use methods in queries .
- User can't use non-public fields in queries as the implicit method invocation is also denied .
...
UnrestrictedMethodAuthorizer
Allow any method execution as long as the target object does not belong to a Geode package, or does belong but it's marked as safe (Region.get, Region.entrySet, Region.keySet, Region.values, Region.getEntries, Region.getValues, Region.containsKey, Region.getKey and Region.getValue). Some known dangerous methods (like getClass) will also be rejected, no matter whether the target object belongs to a Geode package or not. The implementation will be immutable and thread-safe.
...
# Customer deploys the jar and configures the GeodeMethodAuthorizerthe UnrestrictedMethodAuthorizer
$> deploy --jar=/tmp/model-1.0.0.jar
$> alter query-service --method-authorizer=GeodeMethodAuthorizerUnrestrictedMethodAuthorizer
# All classes follow the JavaBean specification 1.01 for accessor methods
...
- The contract for the interface
MethodInvocationAuthorizerwon't include athrowsclause for theNotAuthorizedExceptionclass, that exception was designed to indicate that the subject is not allowed to execute a particular operation, not to indicate that a problem has occurred and that the authorization can not be determined. Since Geode can't do anything to recover from such errors and doesn't have any insights about the actual implementation, a non checked exception should be thrown whenever there's an error while executing the authorization logic. - Authorizer Implementations won't have Based as part of the actual name since the word doesn't add anything useful to the class name.
- Class name for GeodeBasedMethodAuthorizer was changed to UnrestrictedMethodAuthorizer.