[
https://issues.apache.org/jira/browse/SOLR-9057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15269848#comment-15269848
]
Shawn Heisey commented on SOLR-9057:
------------------------------------
I assume you would use /solr/zookeeper for this. With that handler, you can
read the entire ZK chroot used for Solr.
Depending on how zkHost was passed to Solr, it may be visible to users who can
access Solr. If you prevent an attacker from knowing where zookeeper lives,
which I think you can only do if you put it in solr.xml and don't put solr.xml
in zookeeper, any other application besides Solr using that zookeeper will have
some protection. But ... if you're allowing access to Solr itself, the
attacker can do just as much damage within SolrCloud with the collections API
as they could with knowledge of zookeeper's location.
Regarding the actual change being discussed: Unless the solution can put the
info received one way into the same data structure as info received the other
way, implementing this issue means that there will be two code paths for
identical functionality -- one using ZK directly, the other using the HTTP ZK
endpoint. It might be easy to utilize the same data structure either way. I
do not know. If not, then both code paths will need updating whenever related
code evolves.
If you still think it's a good idea, I'm not going to get in your way.
> CloudSolrClient should be able to work w/o ZK url
> -------------------------------------------------
>
> Key: SOLR-9057
> URL: https://issues.apache.org/jira/browse/SOLR-9057
> Project: Solr
> Issue Type: Bug
> Components: SolrJ
> Reporter: Noble Paul
>
> It should be possible to pass one or more Solr urls to Solrj and it should be
> able to get started from there. Exposing ZK to users should not be required.
> it is a security vulnerability
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
