[
https://issues.apache.org/jira/browse/SOLR-17584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17903056#comment-17903056
]
Jason Gerlowski commented on SOLR-17584:
----------------------------------------
This would be a great ticket for a new developer, if anyone is interested in
picking this up prior to 10.0! The primary place that "trustedness" logic is
defined is in ConfigSetService's "isConfigSetTrusted" methods, and the various
places it is used are all pretty easy to trace with the "Find Usages"
capability in modern IDEs.
> Remove code and documentation for "trusted"configsets
> -----------------------------------------------------
>
> Key: SOLR-17584
> URL: https://issues.apache.org/jira/browse/SOLR-17584
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: configset-api, security
> Reporter: Jason Gerlowski
> Priority: Minor
> Labels: newdev
>
> 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
