[jira] [Commented] (SOLR-5617) Default SolrResourceLoader restrictions may be too tight

["Uwe Schindler (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/SOLR-5617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13867287#comment-13867287 ] 

Uwe Schindler commented on SOLR-5617:
-------------------------------------

Hi Shawn,
in fact the code was written exactly to support symbolic links! So your workaround is actually wanted.

The idea of also using the Solr Home directory is theoretically possible, if you would extend SolrResourceLoader.getResource to also look in the parent ResourceLoader. There is already work done that this may work in the future (if ResourceLoaders would have the same parent-child relations like ClassLoaders), but currently its not easy possible.

There is currently also another elegant workaround: If the file is not in the config dir directly, SolrResourceLoader looks in the classpath (through Core's ClassLoader) and tries to find the file from there. So the easiest for you is to add the shared directory as additional "lib" folder to the solrconfig.xml of all cores. You may need to pack the files as JAR, but we can improve solr here, that it might also accept non-jared class path components for lib directives. Thats in fact the most clean solution, also working on windows without symlinks. Also this is easy for the user to understand: Just add another lib / classes / whatevername folder where your shared config files are.

> Default SolrResourceLoader restrictions may be too tight
> --------------------------------------------------------
>
>                 Key: SOLR-5617
>                 URL: https://issues.apache.org/jira/browse/SOLR-5617
>             Project: Solr
>          Issue Type: Bug
>    Affects Versions: 4.6
>            Reporter: Shawn Heisey
>            Priority: Minor
>              Labels: security
>             Fix For: 5.0, 4.7
>
>
> SOLR-4882 introduced restrictions for the Solr class loader that cause resources outside the instanceDir to fail to load.  This is a very good goal, but what if you have common resources like included config files that are outside instanceDir but are still fully inside the solr home?
> I can understand not wanting to load resources from an arbitrary path, but the solr home and its children should be about as trustworthy as instanceDir.
> Ideally I'd like to have anything that's in $\{solr.solr.home\} trusted automatically.  If I need to define a system property to make this happen, I'm OK with that -- as long as I don't have to turn off the safety checking entirely.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org