You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-user@lucene.apache.org by adfel70 <ad...@gmail.com> on 2019/05/02 12:03:28 UTC
Potential authorization bug when making HTTP requests
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
Re: Potential authorization bug when making HTTP requests
Posted by adfel70 <ad...@gmail.com>.
Opened SOLR-13472 <https://issues.apache.org/jira/browse/SOLR-13472>
--
Sent from: http://lucene.472066.n3.nabble.com/Solr-User-f472068.html
Re: Potential authorization bug when making HTTP requests
Posted by Jan Høydahl <ja...@cominvent.com>.
Hi
There has been some work on the 'all' permission lately as well, see e.g. SOLR-13355 <https://issues.apache.org/jira/browse/SOLR-13355> which is not yet released.
Have not analyzed your case to see if it could be related.
I encourage you to test with 8.1 nighlyt https://builds.apache.org/view/L/view/Lucene/job/Solr-Artifacts-8.1/lastSuccessfulBuild/artifact/solr/package/ <https://builds.apache.org/view/L/view/Lucene/job/Solr-Artifacts-8.1/lastSuccessfulBuild/artifact/solr/package/> and see if you can reproduce. If you can still reproduce, consider filing a new bug.
--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com
> 5. mai 2019 kl. 07:34 skrev adfel70 <ad...@gmail.com>:
>
> Hi Jan,
> Thanks for the reply.
> I am not sure it is exactly the same issue, also we are testing with Solr
> 7.7.1 and issue still occurs.
>
>
>
> --
> Sent from: http://lucene.472066.n3.nabble.com/Solr-User-f472068.html
Re: Potential authorization bug when making HTTP requests
Posted by adfel70 <ad...@gmail.com>.
Hi Jan,
Thanks for the reply.
I am not sure it is exactly the same issue, also we are testing with Solr
7.7.1 and issue still occurs.
--
Sent from: http://lucene.472066.n3.nabble.com/Solr-User-f472068.html
Re: Potential authorization bug when making HTTP requests
Posted by Jan Høydahl <ja...@cominvent.com>.
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 <ad...@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