[
https://issues.apache.org/jira/browse/SOLR-17584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17936472#comment-17936472
]
Sanjay Dutt commented on SOLR-17584:
------------------------------------
As per the documentation:
{quote}A configset is uploaded in a "trusted" mode if authentication is enabled
and the upload operation is performed as an authenticated request.
{quote}
And I also checked the code, *requestIsTrusted* is translated to whether
configset is trusted or not. IMO, if we are removing "trustedness" logic and
*requestIsTrusted* is not used anywhere else then yes *requestIsTrusted* should
also be removed.
> 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
