Julian Hyde created CALCITE-5295:
------------------------------------
Summary: Read the values of plugins (such as connect string
properties) from ThreadLocal fields
Key: CALCITE-5295
URL: https://issues.apache.org/jira/browse/CALCITE-5295
Project: Calcite
Issue Type: Bug
Components: avatica
Reporter: Julian Hyde
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:
{code:java}
public class MyClass {
public static final ThreadLocal<AvaticaHttpClientFactoryImpl> INSTANCE =
new ThreadLocal<>();
}
{code}
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.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
