lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Høydahl <jan....@cominvent.com>
Subject Re: Potential authorization bug when making HTTP requests
Date Thu, 02 May 2019 14:39:30 GMT
Fixed in 6.6.6 and 7.7, please upgrade
https://lucene.apache.org/solr/news.html <https://lucene.apache.org/solr/news.html>
https://issues.apache.org/jira/browse/SOLR-12514 <https://issues.apache.org/jira/browse/SOLR-12514>


--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com

> 2. mai 2019 kl. 14:03 skrev adfel70 <adfel70@gmail.com>:
> 
> 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 ...
>  "authorization":{
>  "class":"solr.RuleBasedAuthorizationPlugin",  
>  "permissions":[
>  	{
>  	  "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
> request):
> - 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
> behaviour.
> Is this should be opened as a bug?
> Thanks.
> 
> 
> 
> --
> Sent from: http://lucene.472066.n3.nabble.com/Solr-User-f472068.html


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message