Details
-
Bug
-
Status: Closed
-
Major
-
Resolution: Fixed
-
None
-
None
Description
This change would allow plugin values to come from a field whose type is ThreadLocal. This will be useful in scenarios where the value of the plugin cannot be statically captured in a class, but depends upon the dynamic state of the program. This requirement often occurs during testing.
Avatica allows plug-ins in several places, but most notably connection properties. For example, if I have httpclient_factory=com.example.MyClass#INSTANCE in the connect string, Avatica will look for a static field INSTANCE in class com.example.MyClass and cast it to a AvaticaHttpClientFactoryImpl.
This change would extend that schema to allow instead such fields to be a ThreadLocal, as follows:
public class MyClass { public static final ThreadLocal<AvaticaHttpClientFactoryImpl> INSTANCE = new ThreadLocal<>(); }
The code change would be to the AvaticaUtilsinstantiatePlugin method. Other code using that utility method, such as Calcite, would inherit that functionality.
We should evaluate whether this functionality poses a security risk. In opinion, it does not. To inject a malicious value into the plugin, the attacker need to already control the JVM instantiating the plugin.
If anything, this reduces security risk, because a ThreadLocal allows the value to be set for a shorter duration, and only read/written from the current thread. Therefore malicious threads in the same JVM, or malicious code operating earlier or later in the same thread, cannot interfere.
