Thank you for the reply.
What we are attempting is to require a password for practically everything, so
that even were a hacker to get within the firewall, they would have limited
access to the various services (the Security team even complained that, for
Solr 4.5 servers, attempts to access host:port (without "/solr") resulted in an
error message that gave the full pathname to solr.war)
I am sending the solr.log files directly to Anshum, so as not to clutter up the
Email list.
The steps I used to recreate the problem are as follows:
cd zookeeper-3.4.6/conf/
sed 's/2181/4545/' zoo_sample.cfg | tee zoo_sample4545.cfg
cd ../bin
./zkServer.sh start zoo_sample4545.cfg
cd ../../solr-5.3.1/server/solr
mkdir xmpl
echo 'name=xmpl' | tee xmpl/core.properties
mkdir xmpl/data
mkdir xmpl/data/index
mkdir xmpl/data/tlog
cd ../scripts/cloud-scripts/
./zkcli.sh --zkhost localhost:4545 -cmd makepath /solr
./zkcli.sh --zkhost localhost:4545 -cmd makepath /solr/xmpl
./zkcli.sh --zkhost localhost:4545/solr/xmpl -cmd upconfig -confdir
../../solr/configsets/basic_configs/conf -confname xmpl
mkdir ../../example/solr
cp solr.xml ../../example/solr
./zkcli.sh --zkhost localhost:4545/solr/xmpl -cmd putfile /security.json
~/solr/security151117a.json
cd ../../../bin
mkdir ../example/solr/pid
./solr -c -p 4575 -d ~dbman/solr/straight531outofbox/solr-5.3.1/server/ -z
localhost:4545/solr/xmpl -s
~dbman/solr/straight531outofbox/solr-5.3.1/example/solr
./solr -c -p 4565 -d ~dbman/solr/straight531outofbox/solr-5.3.1/server/ -z
localhost:4545/solr/xmpl -s
~dbman/solr/straight531outofbox/solr-5.3.1/server/solr
curl -u solr:SolrRocks 'http://
{IP-address-redacted}:4575/solr/admin/collections?action=ADDREPLICA&collection=xmpl&shard=shard1&node={IP-address-redacted}:4575_solr&wt=json&indent=true'
The contents of security151117a.json is included in the original post
If there is a better way using the Well Known Permissions as described at
lucidworks.com/blog/2015/08/17/securing-solr-basic-auth-permission-rules, I'm
open to trying that.
I would like to acknowledge that there definitely seem to be some IMPROVEMENTS
in the security.json implementation: particularly in terms of Core Admin (using
jetty-implemented Authentication in webdefault.xml, anyone who could get into
the GUI front page could rename cores, unless prevented by OS-level permissions
on core.properties).
Thanks again
