janhoy opened a new pull request #372: URL: https://github.com/apache/solr/pull/372
https://issues.apache.org/jira/browse/SOLR-11623 This is a back-compat breaking change that likely will require lots of 3rd party request handlers out there to explicitly declare their permission requirement in order to be used with Solr 9. But I think we cannot let this be optional anymore. I added one permission `HEALTH_PERM` for the `/node/health` and `/<coll>/ping` endpoints. That way you can easily open those to the world or connect them to a "health" role that can be given to e.g. solr-operator user. I thought of using the `METRICS_READ_PERM` but that reveals more data. I struggle a bit with what perm to assign to our `/admin/info/system` handler, since it outputs some metrics, some config, all commandline args, some (insensitive) security info etc. I chose `CONFIG_READ_PERM` but this also means that all Admin UI users will need this permission to do almost anything, since Dashboard calls this. The same struggle goes for the `<coll>/analysis/field`, `<coll>/admin/thread` and several others. They reveal some config and sometimes some content. Please review whether things look sane. The `ZookeeperInfoHandler` is special since it allows read of everything in Zookeeper. I tried to give it `CONFIG_READ_PERM`, unless you request `path=/security.json&detail=true`, then it will require `SECURITY_READ_PERM`. Do we have other endpoints in the system that reveal Zookeeper content, where security.json might leak? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
