[ 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