[
https://issues.apache.org/jira/browse/CALCITE-5298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17609242#comment-17609242
]
Julian Hyde commented on CALCITE-5298:
--------------------------------------
I understand why they are necessary, but in my opinion, checks like
{code:java}
} catch (RuntimeException e) {
if (!"java.security.AccessControlException".equals(e.getClass().getName())) {
...
{code}
are mysterious. Is there a way to move the logic from this change and
CALCITE-4823 into {{org.apache.calcite.util.Unsafe}} or
{{org.apache.calcite.util.Compatible}} or similar?
Are there any steps we can take to prevent this problem happening in future?
For instance, should we run CI with a security manager enabled?
> CalciteSystemProperty calcite.test.dataset path check fails under Java
> Security Manager
> ---------------------------------------------------------------------------------------
>
> Key: CALCITE-5298
> URL: https://issues.apache.org/jira/browse/CALCITE-5298
> Project: Calcite
> Issue Type: Bug
> Components: core
> Affects Versions: 1.27.0, 1.28.0, 1.29.0, 1.30.0, 1.31.0, 1.32.0
> Reporter: Kevin Risden
> Assignee: Kevin Risden
> Priority: Major
>
> SOLR-16433 found that Calcite does not handle the Java security manager
> returning permission denied when checking that the calcite.test.dataset path
> exists. Solr runs with a security manager that doesn't allow arbitrary
> filesystem access. This failure causes Calcite to not load and therefore
> unusable.
> The code in question is here:
> https://github.com/apache/calcite/blame/main/core/src/main/java/org/apache/calcite/config/CalciteSystemProperty.java#L189
> A few other places in Calcite already check for SecurityException:
> https://github.com/apache/calcite/search?q=SecurityException
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
