Description
Found a couple of issues around the ACL on /security.json.
First, the ref guide suggests using zkcli.sh to bootstrap the security.json file before launching Solr. However, if users don't know to go uncomment the SOLR_ZK_CREDS_AND_ACLS setting in that file, then the /security.json znode gets created with:
[zk: localhost:2181(CONNECTED) 0] getAcl /security.json
'world,'anyone
: cdrwa
In my opinion, Solr should set the proper ACL on /security.json during startup. I can't think of a valid use-case where someone would not want an ACL set on that file and leave it wide-open?
Second issue is the read-only user, set by -DzkDigestReadonlyUsername=readonly-user when using -DzkCredentialsProvider=org.apache.solr.common.cloud.VMParamsSingleSetCredentialsDigestZkCredentialsProvider has read access to this file! I don't think the readonly-user should get access to /security.json at all. It should not be needed on the SolrJ side (if so that's a bug too). Here's an example of the ACL setup on the /security.json:
[zk: localhost:2181(CONNECTED) 3] addauth digest readonly-user:???? [zk: localhost:2181(CONNECTED) 4] getAcl /security.json 'digest,'admin-user:JXWohwvivCNkIt0wF610qwy12m8= : cdrwa 'digest,'readonly-user:gTm65v03y9NNDb/kShjqJVYk+AI= : r
I can't speak to how vulnerable the hashed passwords stored in security.json are (I suspect the are reasonably safe from brute-force cracking but the algo Solr uses is not computationally slow like bcrypt so there may be some risk here). Even if the risk is low, seems like bad form to me and we should protect security.json from users with read-only access, i.e. SolrJ client applications.
Attachments
Attachments
Issue Links
- is related to
-
SOLR-17207 remove LocaleTest, cleanup test detection of MiniKdc incompatible Locales
-
- Closed
-
-
SOLR-15366
SaslZkACLProviderTest.testSaslZkACLProvider fails
-
- Open
-