[
https://issues.apache.org/jira/browse/SOLR-13355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16808632#comment-16808632
]
ASF subversion and git services commented on SOLR-13355:
--------------------------------------------------------
Commit b135c49d386c14ac2a6476fb9e57ab8a5c74ecf7 in lucene-solr's branch
refs/heads/branch_7_7 from Jason Gerlowski
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=b135c49 ]
SOLR-13355: Obey 'ALL' for handlers with other predefined perms
Prior to this commit, RuleBasedAuthorizationPlugin would check for the
predefined 'ALL' permission only when the endpoint being hit wasn't
associated with another predefined-permission.
This resulted in some very unintuitive behavior. For example, the
permission {name:all, role:admin} would correctly prevent a
role:foo user from accessing /admin/info/properties, but would allow
write access to /admin/authorization because of the SECURITY_EDIT
predefined perm associated with that endpoint.
This commit fixes this bug so that the 'all' permission is always
consulted whether or not the endpoint is associated with other predefined
permissions.
> RuleBasedAuthorizationPlugin ignores "all" permission for most handlers
> -----------------------------------------------------------------------
>
> Key: SOLR-13355
> URL: https://issues.apache.org/jira/browse/SOLR-13355
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: security
> Affects Versions: 7.5, 8.0, master (9.0)
> Reporter: Jason Gerlowski
> Assignee: Jason Gerlowski
> Priority: Major
> Attachments: SOLR-13355.patch
>
>
> 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!
> {code}
> {
> "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"
> }}}
> {code}
> 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|https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/security/RuleBasedAuthorizationPlugin.java#L122].
> 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.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
