[
https://issues.apache.org/jira/browse/SOLR-13472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16885194#comment-16885194
]
Jason Gerlowski commented on SOLR-13472:
----------------------------------------
bq. Attaching a patch. As per this, the authorization should only be performed
on a node if the request is to be executed on that node. Skips authorization on
a node if the request has to be forwarded to another node.
I like the simplicity of this approach, but have one doubt/concern. Is it a
security/performance issue to be forwarding requests around internally that we
haven't validated yet? The more file-handles, request threads, etc. Solr
spends on requests that haven't been auth'd yet, the easier it would be (in
theory) for a malicious user to gum up the system.
That said, "in theory" is a long way from "in practice". Maybe the additional
resources spent forwarding requests on that would previously have been rejected
at the receiving node are negligible and wouldn't have any sort of real world
impact. Just curious whether you considered or experimented with this at all?
> HTTP requests to a node that does not hold a core of the collection are
> unauthorized
> ------------------------------------------------------------------------------------
>
> Key: SOLR-13472
> URL: https://issues.apache.org/jira/browse/SOLR-13472
> Project: Solr
> Issue Type: Bug
> Components: Authorization
> Affects Versions: 7.7.1, 8.0
> Reporter: adfel
> Assignee: Ishan Chattopadhyaya
> Priority: Minor
> Labels: security
> Fix For: 8.2
>
> Attachments: SOLR-13472.patch, SOLR-13472.patch
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> When creating collection in SolrCloud, collection is available for queries
> and updates through all Solr nodes, in particular nodes that does not hold
> one of collection's cores. This is expected behaviour that works when using
> SolrJ client or HTTP requests.
> When enabling authorization rules it seems that this behaviour is broken for
> HTTP requests:
> - executing request to a node that holds part of the collection (core) obey
> to authorization rules as expected.
> - other nodes respond with code 403 - unauthorized request.
> SolrJ still works as expected.
> Tested both with BasicAuthPlugin and KerberosPlugin authentication plugins.
> +Steps for reproduce:+
> 1. Create a cloud made of 2 nodes (node_1, node_2).
> 2. Configure authentication and authorization by uploading following
> security.json file to zookeeper:
>
> {code:java}
> {
> "authentication": {
> "blockUnknown": true,
> "class": "solr.BasicAuthPlugin",
> "credentials": {
> "solr": "'solr' user password_hash",
> "indexer_app": "'indexer_app' password_hash",
> "read_user": "'read_user' password_hash"
> }
> },
> "authorization": {
> "class": "solr.RuleBasedAuthorizationPlugin",
> "permissions": [
> {
> "name": "read",
> "role": "*"
> },
> {
> "name": "update",
> "role": [
> "indexer",
> "admin"
> ]
> },
> {
> "name": "all",
> "role": "admin"
> }
> ],
> "user-role": {
> "solr": "admin",
> "indexer_app": "indexer"
> }
> }
> }{code}
>
> 3. create 'test' collection with one shard on *node_1*.
> --
> The following requests expected to succeed but return 403 status
> (unauthorized request):
> {code:java}
> curl -u read_user:read_user "http://node_2/solr/test/select?q=*:*";
> curl -u indexer_app:indexer_app "http://node_2/solr/test/select?q=*:*";
> curl -u indexer_app:indexer_app "http://node_2/solr/test/update?commit=true";
> {code}
>
> Authenticated '_solr_' user requests works as expected. My guess is due to
> the special '_all_' role.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
