You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "ASF subversion and git services (JIRA)" <ji...@apache.org> on 2019/04/03 11:36:00 UTC
[jira] [Commented] (SOLR-13355) RuleBasedAuthorizationPlugin
ignores "all" permission for most handlers
[ https://issues.apache.org/jira/browse/SOLR-13355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16808626#comment-16808626 ]
ASF subversion and git services commented on SOLR-13355:
--------------------------------------------------------
Commit 68918206f56fc7a65ce9b84a9cf6a30edf8ce7c2 in lucene-solr's branch refs/heads/branch_8x from Jason Gerlowski
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=6891820 ]
SOLR-13355: Small refactors to RuleBasedAuthorizationPlugin
> 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org