[
https://issues.apache.org/jira/browse/SOLR-15151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17289081#comment-17289081
]
Thomas Mortagne edited comment on SOLR-15151 at 2/23/21, 1:35 PM:
------------------------------------------------------------------
One important problem with the current logic in assertPathAllowed is that it
miss a lot of cases if you really want to protect against manipulating a path
which is not allowed because it assumes that anything which does not start with
".." is a child of an allowed path, but you work around that with "./.." (or
pretty much anything before the "..") for example. That pretty much make it
totally useless while preventing perfectly valid use cases...
The only real way to do proper protection would be to work with absolute paths
and I that means moving the assertPathAllowed call to where those paths are
resolved which is usually in a very different place from what I saw (my use
case being the data folder).
I could propose a pull request to allow paths starting with ".." in
assertPathAllowed as suggested in
https://issues.apache.org/jira/browse/SOLR-14561?focusedCommentId=17283071&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17283071
but honestly it does not seems much cleaner than hacking it with some
workaround I suggested (like simply adding "./" as suffix of the relative
path). I really feel that the whole logic of assertPathAllowed need to be
rethink (or reverted) as it does not really do what it's supposed to right now.
was (Author: tmortagne):
One important problem with the current logic in assertPathAllowed is that it
miss a lot of cases if you really want to protect against manipulating a path
which is not allowed because it assumes that anything which does not start with
".." is a child of an allowed path, but you work around that with "./.." (or
pretty much anything before the "..") for example. That pretty much make it
totally useless while preventing perfectly valid use cases...
The only real way to do proper protection would be to only work with absolute
paths and I guess that means moving the assertPathAllowed call to where those
paths are resolved which is usually in a very different place from what I saw
(my use case being the data folder).
I could propose a pull request to allow paths starting with ".." in
assertPathAllowed as suggested in
https://issues.apache.org/jira/browse/SOLR-14561?focusedCommentId=17283071&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17283071
but honestly it does not seems much cleaner than hacking it with some
workaround I suggested (like simply adding "./" as suffix of the relative
path). I really feel that the whole logic of assertPathAllowed need to be
rethink (or reverted) as it does not really do what it's supposed to right now.
> It's not possible anymore to indicate a relative path to the core data folder
> -----------------------------------------------------------------------------
>
> Key: SOLR-15151
> URL: https://issues.apache.org/jira/browse/SOLR-15151
> Project: Solr
> Issue Type: Bug
> Affects Versions: 8.6
> Reporter: Thomas Mortagne
> Priority: Major
>
> See
> https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.8.0/solr/core/src/java/org/apache/solr/core/SolrPaths.java#L124.
> SOLR-14561 introduced a check to forbid using a path starting with "../" for
> the data of a core. This makes impossible to indicate a relative path to a
> data folder which is not stored in the core folder itself. Og course you can
> set an absolute path (provided it's part of the allowed paths), but then it
> makes impossible to move the entire storage somewhere else because it will
> break the stored path.
> IMO the check for "../" prefix should be completely removed, and instead
> relative paths should be resolved to check if they are part of the allowed
> paths. At least for my use case having to set allowed paths is fine but it's
> possible some people might want to completely disable allowed path system.
--
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
