[
https://issues.apache.org/jira/browse/SOLR-15249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Drob updated SOLR-15249:
-----------------------------
Security: (was: Private (Security Issue))
> Zookeeper ACL on /security.json
> -------------------------------
>
> Key: SOLR-15249
> URL: https://issues.apache.org/jira/browse/SOLR-15249
> Project: Solr
> Issue Type: Bug
> Components: security
> Reporter: Timothy Potter
> Assignee: Mike Drob
> Priority: Major
> Fix For: main (9.0), 8.9, 8.8.2
>
> Attachments:
> 0001-SOLR-15249-Properly-set-ZK-ACLs-on-security.json.patch,
> 0002-Update-Ref-Guide.patch,
> 0003-SOLR-15249-Attempt-to-repair-ACLs-on-startup.patch, SOLR-15249.patch
>
>
> 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:
> {code}
> [zk: localhost:2181(CONNECTED) 0] getAcl /security.json
> 'world,'anyone
> : cdrwa
> {code}
> 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:
> {code}
> [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
> {code}
> 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.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
