[
https://issues.apache.org/jira/browse/SOLR-16781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17718660#comment-17718660
]
Gus Heck commented on SOLR-16781:
---------------------------------
I think the trusted/untrusted construct is a key pain point. I'm not familiar
enough with the other two features that seem to require it to know if we can
eliminate that complexity but there might be a way to simplify <lib> handling
that removes the need for trusted/untrusted in its case.
Rather than getting rid of <lib> entirely, change it so that by default, it
throws an error for anything outside the solr classpath. Then add a startup
level configuration that adds directories to the legal locations for <lib>.
This could be some combination of sysprops/environment or even something in the
possible replacement for solr.in.sh contemplated by SOLR-7871. We can debate if
these locations can be recursive, and what to do (if anything) about symlinks.
Thus we wind up with a two stage process:
# The folks who install solr define the playground
# The folks who interact with solr do whatever they are permitted to within
that playground.
Ideally in addition to throwing an error when the config set tries to load the
upload process would also run this check on any files uploaded to fail fast and
friendly for the user.
This way would have the benefit that organizations can tune their installation
to be as strict or permissive as they like. We should create good clear
documentation explaining that allowing libraries to be loaded from a location
to which untrusted (or less trusted) users can cause a file to be written (via
solr or otherwise) makes it possible for those with config-edit to effectively
install code. If they want to run with scissors, knowing the danger, let them,
just don't make it the default.
> 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]
