[
https://issues.apache.org/jira/browse/SOLR-12514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16535892#comment-16535892
]
Hrishikesh Gadre commented on SOLR-12514:
-----------------------------------------
[~janhoy]
{quote}Not really, If we only return 302 in case A: auth+autz is enabled anf B:
current node does not host the collection. Rather force client change rather
than staying insecure.
{quote}
Well...currently Solr does not return 302 response in the case that you
mentioned (auth+autz is enabled and current node does not host the collection).
So from client perspective this indeed is a backwards incompatible change. This
security issue is a design limitation of the Solr security framework and
ideally it should be fixed without affecting the current client/server
interaction semantics.
The third option seems better as it addresses the design limitation (that any
node can figure out the handler class name for a given request). Can we just
read the solrconfig.xml for all the collections and prepare this mapping at the
startup? This can be a lightweight code which does not involve spinning up a
core.
> Rule-base Authorization plugin skips authorization if querying node does not
> have collection replica
> ----------------------------------------------------------------------------------------------------
>
> Key: SOLR-12514
> URL: https://issues.apache.org/jira/browse/SOLR-12514
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: security
> Affects Versions: 7.3.1
> Reporter: Mahesh Kumar Vasanthu Somashekar
> Priority: Major
> Attachments: SOLR-12514.patch, Screen Shot 2018-06-24 at 9.36.45
> PM.png, security.json
>
>
> Solr serves client requests going throught 3 steps - init(), authorize() and
> handle-request ([link
> git-link|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/7.3.1/solr/core/src/java/org/apache/solr/servlet/HttpSolrCall.java#L471]).
> init() initializes all required information to be used by authorize().
> init() skips initializing if request is to be served remotely, which leads to
> skipping authorization step ([link
> git-link|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/7.3.1/solr/core/src/java/org/apache/solr/servlet/HttpSolrCall.java#L291]).
> init() relies on 'cores' object which only has information of local node
> (which is perfect as per design). It should actually be getting security
> information (security.json) from zookeeper, which has global view of the
> cluster.
>
> Example:
> SolrCloud setup consists of 2 nodes (solr-7.3.1):
> live_nodes: [
> "localhost:8983_solr",
> "localhost:8984_solr",
> ]
> Two collections are created - 'collection-rf-1' with RF=1 and
> 'collection-rf-2' with RF=2.
> Two users are created - 'collection-rf-1-user' and 'collection-rf-2-user'.
> Security configuration is as below (security.json attached):
> "authorization":{
> "class":"solr.RuleBasedAuthorizationPlugin",
> "permissions":[
> { "name":"read", "collection":"collection-rf-2", "role":"collection-rf-2",
> "index":1}
> ,
> { "name":"read", "collection":"collection-rf-1", "role":"collection-rf-1",
> "index":2}
> ,
> { "name":"read", "role":"*", "index":3}
> ,
> ...
> "user-role":
> { "collection-rf-1-user":[ "collection-rf-1"], "collection-rf-2-user":[
> "collection-rf-2"]}
> ,
> ...
>
> Basically, its setup to that 'collection-rf-1-user' user can only access
> 'collection-rf-1' collection and 'collection-rf-2-user' user can only access
> 'collection-rf-2' collection.
> Also note that 'collection-rf-1' collection replica is only on
> 'localhost:8983_solr' node, whereas ''collection-rf-2' collection replica is
> on both live nodes.
>
> Authorization does not work as expected for 'collection-rf-1' collection:
> $ curl -u collection-rf-2-user:password
> 'http://*localhost:8983*/solr/collection-rf-1/select?q=*:*'
> <html>
> <head>
> <meta http-equiv="Content-Type" content="text/html;charset=utf-8"/>
> <title>Error 403 Unauthorized request, Response code: 403</title>
> </head>
> <body><h2>HTTP ERROR 403</h2>
> <p>Problem accessing /solr/collection-rf-1/select. Reason:
> <pre> Unauthorized request, Response code: 403</pre></p>
> </body>
> </html>
> $ curl -u collection-rf-2-user:password
> 'http://*localhost:8984*/solr/collection-rf-1/select?q=*:*'
> {
> "responseHeader":{
> "zkConnected":true,
> "status":0,
> "QTime":0,
> "params":{
> "q":"*:*"}},
> "response":{"numFound":0,"start":0,"docs":[]
> }}
>
> Whereas authorization works perfectly for 'collection-rf-2' collection (as
> both nodes have replica):
> $ curl -u collection-rf-1-user:password
> 'http://*localhost:8984*/solr/collection-rf-2/select?q=*:*'
> <html>
> <head>
> <meta http-equiv="Content-Type" content="text/html;charset=utf-8"/>
> <title>Error 403 Unauthorized request, Response code: 403</title>
> </head>
> <body><h2>HTTP ERROR 403</h2>
> <p>Problem accessing /solr/collection-rf-2/select. Reason:
> <pre> Unauthorized request, Response code: 403</pre></p>
> </body>
> </html>
> $ curl -u collection-rf-1-user:password
> 'http://*localhost:8983*/solr/collection-rf-2/select?q=*:*'
> <html>
> <head>
> <meta http-equiv="Content-Type" content="text/html;charset=utf-8"/>
> <title>Error 403 Unauthorized request, Response code: 403</title>
> </head>
> <body><h2>HTTP ERROR 403</h2>
> <p>Problem accessing /solr/collection-rf-2/select. Reason:
> <pre> Unauthorized request, Response code: 403</pre></p>
> </body>
> </html>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
