[
https://issues.apache.org/jira/browse/SOLR-12514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16522660#comment-16522660
]
Hrishikesh Gadre commented on SOLR-12514:
-----------------------------------------
Yes I also have observed this behavior with [Solr Sentry authorization
plugin|https://github.com/apache/sentry/blob/74842080936b93a8ef9b874774fd841764adc42c/sentry-binding/sentry-binding-solr/src/main/java/org/apache/sentry/binding/solr/authz/SentrySolrPluginImpl.java].
The root cause was the fact that the authorization framework relies on
PermissionNameProvider interface to figure out the permissions to be checked
against the authorization database. The individual request handlers in Solr are
expected to implement this interface so as to define which permissions to check
for which functionality. Now in case a core is not available on a given Solr
server, the authorization context provides null value for the request handler.
The Sentry plugin performs an "instanceof" check against the request handler
reference. If this check fails (either because the request handler is null or
does not implement PermissionNameProvider interface), it approves the request
anyway. This is required since there are many request handlers in Solr which
don't support authorization (Ref: SOLR-11623) and the authorization plugin
needs to play nice with these request handlers. Now once the request is
approved by the authorization plugin, the forwarded request is executed as a
solr admin user (which has all the permissions). As a result, an user without
authorization can see the query results.
The fix was to use the "proxy users" functionality provided by the Hadoop
authentication plugin. In this case, Solr automatically applies a "doAs"
parameter to the query being forwarded to the remote solr server. This forces
the remote Solr instance to treat this as a request from original user instead
of from solr admin. Hence when it performs the authorization check, the request
is rejected appropriately. This fix works well in our environment because we
only support Hadoop authentication plugin which has "proxy users" support. We
will need to think about generic solution for it to be applicable for all
users. Let me upload the patch for reference.
> 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: 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]
