[
https://issues.apache.org/jira/browse/CALCITE-5295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde reassigned CALCITE-5295:
------------------------------------
Assignee: Julian Hyde
> 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
> Assignee: Julian Hyde
> Priority: Major
> Fix For: avatica-1.23.0
>
>
> 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)
