Major Description
RuleBasedAuthorizationPlugin defines a set of predefined permission rules that users can use ootb to lock down sets of APIs to different roles (and ultimately, users). The widest of these, the "all" permission is intended to be a catch-all that covers all requests not handled by an earlier rule.
But in practice, "all" doesn't seem to have any effect on most endpoints. For example, the security.json below will still allow the readonly user to hit almost all endpoints!
{
"authentication": {
"blockUnknown": true,
"class": "solr.BasicAuthPlugin",
"credentials": {
"readonly": "<pw>",
"admin": "<pw>"}},
"authorization": {
"class": "solr.RuleBasedAuthorizationPlugin",
"permissions": [
{"name":"read","role": "*"},
{"name":"schema-read", "role":"*"},
{"name":"config-read", "role":"*"},
{"name":"collection-admin-read", "role":"*"},
{"name":"metrics-read", "role":"*"},
{"name":"core-admin-read","role":"*"},
{"name": "all", "role": "admin_role"}
],
"user-role": {
"readonly": "readonly_role",
"admin": "admin_role"
}}}
It looks like this happens because we neglect to check for the "all" special case in the branch of code that gets triggered for Handlers that implement PermissionNameProvider. See here.
e.g. With the security.json above if the "readonly" user makes a request to /admin/authorization, the PermissionNameProvider will return SECURITY_EDIT. When deciding whether the "all" permission applies to that endpoint, the code compares SECURITY_EDIT to ALL, sees they don't match, and decides that "all" doesn't apply.