[
https://issues.apache.org/jira/browse/SOLR-17584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17936945#comment-17936945
]
David Smiley commented on SOLR-17584:
-------------------------------------
Big +1 from me for removing the distinction of a "trusted" configSet. It's not
worth the burden on the project (Solr) on somehow upholding some security
guarantees for some configSets but not others. Users running Solr need to know
that authoring configSets requires administrative level trust, with or without
"lib" directives. Therefore, whatever the path is from configSets into Solr
needs to be guarded/secured so that anyone untrusted can't publish or tamper
with them.
> Remove code and documentation for "trusted"configsets
> -----------------------------------------------------
>
> Key: SOLR-17584
> URL: https://issues.apache.org/jira/browse/SOLR-17584
> Project: Solr
> Issue Type: Improvement
> Components: configset-api, security
> Reporter: Jason Gerlowski
> Priority: Minor
> Labels: newdev, pull-request-available
> Time Spent: 1h
> Remaining Estimate: 0h
>
> SOLR-16781 removed the ability for configsets to load code and resources
> using "<lib>" directives.
> These (now removed) "<lib>" directives were the primary motivation for the
> trusted/untrusted configset distinction that was evolved over time to
> restrict which configs/collections could load external libraries. Now that
> they're gone, we should remove code and documentation related to the
> trusted/untrusted distinction.
> Technically, several components (XSLTUpdateRequestHandler,
> ScriptUpdateRequestProcessor) still check configset "trustedness" when being
> loaded. But both of these components require enabling a module at startup
> time (e.g. {{SOLR_MODULES=scripting}}. And if an administrator has already
> put these things on the classpath, layering "trustedness" on top of that
> doesn't seem to add any value or security. (Especially given that the
> "trustedness" determination itself probably shouldn't be relied on, due to
> the number of gaps found in it over the years. In fact this is the main
> motivation for the recent removal of <lib> in the first place.)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
