[
https://issues.apache.org/jira/browse/SOLR-4882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13671398#comment-13671398
]
Uwe Schindler edited comment on SOLR-4882 at 5/31/13 12:37 PM:
---------------------------------------------------------------
Attached is the patch implementing this with a system property.
The patch revisits the current logic of the open resource call of
SolrResourceLoader and also fixes some possible bugs. It also uses the "hack"
to make tests work only when the test mode of Solr is enabled. This closes more
"leaks" that can be used.
This should also improve security of
All tests pass, some tests had to be changed:
- 2 tests needed the sysprop set, because they were explicitely testing the
access to absolute paths
- Some missing close() on SolrResourceLoader was added to get rid of warnings
in Eclipse.
- One test was changed to SolrTestCaseJ4, so the test mode was correctly
enabled (this was not needed before, so it extended LuceneTestCase only)
The Solr example starts successfully and I have seen no problems. If you are
affected by this change you get an IOException warpped by the SolrException
explaining that you may enable the mode for escaping the restricted resource
loader.
The test if the path is from inside the restricted path is done by transforming
the file paths (absolute path, not canonic path, to enable playing with
symlinks pointing from Solr conf directory to the outside) to URIs and then
trying to relativize the URI, which is only possible if the normalized (./..
removed) URIs start with the same prefix and are not opaque. If this fails, the
paths are considered as not related and the restriction is enforced.
Tell me what you think, Hoss & others. We don't need to hurry.
was (Author: thetaphi):
Attached is the patch implementing this with a system property.
The patch revisits the current logic of the open resource call of
SolrResourceLoader and also fixes some possible bugs. It also uses the "hack"
to make tests work only when the test mode of Solr is enabled. This closes more
"leaks" that can be used.
This should also improve security of
All tests pass, some tests had to be changed:
- 2 tests needed the sysprop set, because they were explicitely testing the
access to absolute paths
- Some missing close() on SolrResourceLoader was added to get rid of warnings
in Eclipse.
- One test was changed to SolrTestCaseJ4, so the test mode was correctly
enabled (this was not needed before, so it extended LuceneTestCase only)
The Solr example starts successfully and I have seen no problems. If you are
affected by this change you get an IOException warpped by the SolrException
explaining that you may enable the mode for escaping the restricted resource
loader.
Tell me what you think, Hoss & others. We don't need to hurry.
> Restrict SolrResourceLoader to only classloader accessible files and instance
> dir
> ---------------------------------------------------------------------------------
>
> Key: SOLR-4882
> URL: https://issues.apache.org/jira/browse/SOLR-4882
> Project: Solr
> Issue Type: Improvement
> Affects Versions: 4.3
> Reporter: Uwe Schindler
> Assignee: Uwe Schindler
> Fix For: 5.0, 4.4
>
> Attachments: SOLR-4882.patch
>
>
> SolrResourceLoader currently allows to load files from any
> absolute/CWD-relative path, which is used as a fallback if the resource
> cannot be looked up via the class loader.
> We should limit this fallback to sub-dirs below the instanceDir passed into
> the ctor. The CWD special case should be removed, too (the virtual CWD is
> instance's config or root dir).
> The reason for this is security related. Some Solr components allow to pass
> in resource paths via REST parameters (e.g. XSL stalesheets,...) and load
> them via resource loader. By this it is possible to limit the whole thing to
> not allow loading e.g. /etc/passwd as a stylesheet.
> In 4.4 we should add a solrconfig.xml setting to enable the old behaviour,
> but disable it by default, if your existing installation requires the files
> from outside the instance dir which are not available via the URLClassLoader
> used internally. In Lucene 5.0 we should not support this anymore.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
