[
https://issues.apache.org/jira/browse/SOLR-14285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17159229#comment-17159229
]
Andras Salamon commented on SOLR-14285:
---------------------------------------
We also similar problems with the {{<lib>}} directive. I think it's more
caused by SOLR-14071 and not SOLR-6736 alone. We had several use cases where we
have problems:
* In an unsecure environment all configsets are untrusted which basically
makes it impossible to use the {{<lib>}} directives. On the other hand in an
unsecure environment, the trusted flag can be changed, so this strictness
doesn't really prevent anything.
* Upgrading from a pre-8.4 (in our case 7.4) to 8.4 is painful because the old
configsets are untrusted and unfortunately most of them contain <lib>
directives.
* Changing from unsecure environment to secure is also difficult if we already
have configsets.
Our idea was rather similar:
* Instead of stopping core loading, we just ignore the lib directives in an
unsecure environment. According to our experiences, most of the time those are
just copied from some default configset and we don't really need the libraries.
* We introduced a similar java property if someone really wants to load the
libraries, but we only accept this in an unsecure environment, I found it a bit
dangerous to allow to turn off the lib restriction in a secure environment.
Sadly, finding out if we are in a secure or unsecure environment is not that
easy, I had to modify lots of methods to pass a new isSecure parameter. Just
like SOLR-14071 modified some of the same methods when introduced isTrusted.
I'm not sure about this patch, but upload it to start the discussion. Please
consider it as a work-in-progress patch.
> Trusted configset limitations should be relaxed in some circumstances
> ---------------------------------------------------------------------
>
> Key: SOLR-14285
> URL: https://issues.apache.org/jira/browse/SOLR-14285
> Project: Solr
> Issue Type: Improvement
> Components: configset-api
> Affects Versions: 8.4, 8.4.1
> Reporter: Cassandra Targett
> Priority: Major
> Attachments: SOLR-14285-wip.patch
>
>
> The changes in SOLR-6736 mean that as of 8.4, a configset that includes <lib>
> directives will only work if Solr has authentication configured.
> I think we should be able to disable this (on by default) - in dev
> environments, setting up authentication may be overly onerous and an obstacle
> to getting started. These environments can already be well-protected by
> internal firewalls if Solr does not yet need to be accessed.
> Another way that change complicates things is on upgrades. Having your entire
> Solr break only because you have not enabled authc (and maybe you don't
> intend to) and used the default configset is a really poor user experience.
> Similarly, the REINDEXCOLLECTION command copies an existing configset for the
> new collection that it creates while reindexing the documents from a source
> collection. When {{async=false}}, any errors are swallowed making it
> difficult to know this restriction is the cause. I think it would be fair for
> a user to assume that because the configset was already in use that copying
> it to a new collection should be OK (more of an internal thing than a new
> upload).
> Maybe some of this is just a problem for users trying to go from 8.3 to 8.4,
> but it's creating a rather messy & painful upgrade experience. I still think
> it would be worth being able to disable the check with a startup param
> (something like {{-Ddisable.lib.restriction=true}}).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
