[
https://issues.apache.org/jira/browse/SOLR-18579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18131166#comment-18131166
]
Amrit Sarkar commented on SOLR-18579:
-------------------------------------
[~gerlowskija], ran into this while building the query insights module
([SOLR-18572|https://issues.apache.org/jira/browse/SOLR-18572], under
[SOLR-18571|https://issues.apache.org/jira/browse/SOLR-18571]). Its top queries
endpoint is a JAX-RS v2 API guarded by {{config-read}}. My integration test
gave a user only {{config-read}}, with an {{all}} rule for admin, and the user
kept getting 403 on {{GET /api/node/query-insights/top-queries}}. Dropping the
{{all}} rule made it pass, which led me back to the double authorization in
SOLR-17708.
I went with your suggestion there: {{V2HttpCall}} overrides
{{shouldAuthorize()}} and skips the {{HttpSolrCall}} check when no native v2
{{Api}} is resolved, so {{SolrRequestAuthorizer}} is the only check for JAX-RS
resources.
PR: [apache/solr#5214|https://github.com/apache/solr/pull/5214]
Would you be able to take a look? If it covers SOLR-17708 fully, I'm happy to
close that one too.
> v2 node APIs deny users whose predefined permission matches when an "all"
> rule exists
> -------------------------------------------------------------------------------------
>
> Key: SOLR-18579
> URL: https://issues.apache.org/jira/browse/SOLR-18579
> Project: Solr
> Issue Type: Bug
> Components: Authorization, v2 API
> Reporter: Amrit Sarkar
> Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> With {{RuleBasedAuthorizationPlugin}} and a catch-all {{all}} permission, a
> user whose only grant is a predefined permission such as {{metrics-read}}
> gets a 403 from container-level JAX-RS v2 APIs that require exactly that
> permission. The v1 equivalent works.
> ||Request||Permissions||User role||Result||
> |{{GET /solr/admin/metrics}}|{{metrics-read}}: metrics, {{all}}:
> admin|metrics|allowed|
> |{{GET /api/metrics}}|{{metrics-read}}: metrics, {{all}}: admin|metrics|403|
> |{{GET /api/metrics}}|{{metrics-read}}: metrics|metrics|allowed|
> This follows from SOLR-17708. The first check, in {{HttpSolrCall.call()}},
> builds its context from {{V2HttpCall._getHandler()}}, which returns {{api}}.
> For a JAX-RS container API {{api}} is null, so
> {{RuleBasedAuthorizationPluginBase.predefinedPermissionAppliesToRequest}}
> skips every predefined permission except {{all}}. The {{all}} rule then
> governs and denies the request before {{SolrRequestAuthorizer}} checks the
> method's {{@PermissionName}}.
> {noformat}
> Request handler [null] is not a PermissionNameProvider, perm doesnt apply
> 'ALL' perm applies to all requests; perm applies.
> Found perm [{"name":"all","role":"admin"}] to govern resource
> [/____v2/metrics]
> ... BasicAuthPlugin [username=mu,pwd=*****] does not have the right role
> {noformat}
> It fails closed, so it isn't a security hole, but it makes predefined
> permissions unusable on these APIs in a common setup. Other container APIs
> with a non-{{all}} {{@PermissionName}}, such as {{/api/node/threads}}, are
> likely affected the same way. No existing test covers a non-{{all}}
> predefined permission against a container-level JAX-RS API.
> Skipping the {{HttpSolrCall}} check for JAX-RS requests, as suggested on
> SOLR-17708, should fix it. A test with a {{metrics-read}}-only user plus an
> {{all}} rule would pin it.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
