[
https://issues.apache.org/jira/browse/SOLR-16781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17718712#comment-17718712
]
Jan Høydahl commented on SOLR-16781:
------------------------------------
PS: solr.xml loading from ZK is deprecated and gone in 10.0. But a config in
solr.xml similar to solr.allowPaths makes sense.
{code:java}
<str name="allowPaths">${solr.allowPaths:}</str> {code}
The default could be empty set, i.e. nothing allowed, and it would be up to
users to define defaults. There could be a few special values: "*" means allow
all, for quick back-compat etc. Or would it be enough to simply fail if any
<lib> is outside the already defined solr.allowPaths (which defaults to
$SOLR_HOME, $SOLR_DATA_HOME & coreRootDir?
> Remove <lib> directives from Solr
> ---------------------------------
>
> Key: SOLR-16781
> URL: https://issues.apache.org/jira/browse/SOLR-16781
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Ishan Chattopadhyaya
> Priority: Major
>
> <lib> directives in solrconfig.xml used to be recommended way for including
> additional jar files to the classpath for a particular collection or
> collections.
> For context: This feature required complex handling of "trusted" vs
> "non-trusted" configsets in configset upload API to keep Solr secure (i.e. to
> stop RCE attacks for non-authentication enabled deployments). This security
> feature also broke down recently due to a bug in Schema designer (SOLR-16777).
> Supported alternatives exist that are safer:
> * user can add the jar files to Solr's classpath
> * use packages to use custom jars per collection
> In the light of these, there's no need to continue to support the <lib>
> directive going forward.
> I propose to remove the <lib> directives handling and functionality through
> this issue.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
