lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From adfel70 <>
Subject Potential authorization bug when making HTTP requests
Date Thu, 02 May 2019 12:03:28 GMT
Atuhorization bug (?) when making HTTP requests

We are experiencing a problem when making HTTP requests to a cluster with
authorization plugin enabled.
Permissions are configured in security.json the following:

 ... authentication_settings ...
  	  "name": "read",
      "role": "*"
  	  "name": "update",
      "role": ["indexer", "admin"]
  	  "name": "all",
      "role": "admin"
  "user-role": {
  	"admin_user": "admin",
  	"indexer_app": "indexer"

Our goal is to give all users read-only access to the data, read+write
permissions to indexer_app user and full permissions to admin_user.

While testing the ACLs with different users we encountered unclear results,
where in some cases a privileged user got HTTP 403 response (unauthorized
- in some calls authenticated reader could query the data.
- in some calls 'indexer_app' user could query data nor update the data.
- 'admin_user' worked as expected.
In addition, the problems were only relevant to HTTP requests - SolrJ
requests were perfect...

After further investigation we realized what seems to be the problem: HTTP
requests works correctly only when the collection has a core on the server
that got the initial request. For example:
Say we have a cloud made of 2 servers - 'host1' and 'host2' and collection
'test' with one shard - core on host1:

curl -u *reader_user*:XXXX "http://host1:8983/solr/test/select?q=*:*"               
--> code 200 as expected
curl -u *reader_user*:XXXX "http://host2:8983/solr/test/select?q=*:*"               
--> code 403 (error - should return result)

curl -u *indexer_app*:XXXX "http://host1:8983/solr/test/select?q=*:*"               
--> code 200 as expected
curl -u *indexer_app*:XXXX "http://host1:8983/solr/test/update?commit=true" 
--> code 200 as expected
curl -u *indexer_app*:XXXX "http://host2:8983/solr/test/select?q=*:*"               
--> code 403 (error - should return result)
curl -u *indexer_app*:XXXX "http://host2:8983/solr/test/update?commit=true" 
--> code 403 (error - should return result)

We guess 'admin_user' does not encounter any error due to the special
/'all'/ permission.
Tested both using basic and Kerberos authentication plugins and got the same
Is this should be opened as a bug?

Sent from:

View raw message