Uwe Schindler created SOLR-16907:
------------------------------------
Summary: Strange behaviour after upgrade to 9.x when security json
has no longer existing permission
Key: SOLR-16907
URL: https://issues.apache.org/jira/browse/SOLR-16907
Project: Solr
Issue Type: Bug
Security Level: Public (Default Security Level. Issues are Public)
Components: Authentication, Authorization
Affects Versions: 9.3, 9.2, 9.1, 9.0
Reporter: Uwe Schindler
Attachments: security.json
I had a very strange behaviour of Authorization after migrating a standalone
solr instance to Solr 9.
To reproduce, place the attached [^security.json] in the solr.home (it has
default password "SolrRocks"). The only change I did was adding
{{"blockUnknown":false}}, because the whole idea of the file is just to prevent
people doing some changes to configuration, but all queries/select/.... should
work without authentication (basically to prevent the developers from accessing
admin UI and change something).
After applying this config, all requests to any core were denied with
"Authentication failed, Response code: 401". This message does not come from
the "BasicAuthenticationProvider" (hint: if you enable "blockUnknown", it fails
earlier and print as error message: "require authentication" coming from
BasicAuthenticationProvider). So the problem was not caused by the setting
"blockUnknown=false" ignored.
It took me a long time to actually find the reason and without enabling debug
logging and going through all settings I found the issue. This is totally
unexpected and should be fixed as no warning or reason is printed to default
log.
{noformat}
2023-07-27 08:48:23.929 DEBUG (qtp1963075870-46) [] o.e.j.s.h.ContextHandler
scope null||/solr/techproducts/select @
o.e.j.w.WebAppContext@49a64d82{solr-jetty-context.xml,/solr,file:///C:/Users/Uwe%20Schindler/Desktop/solr-9.3.0-slim/server/solr-webapp/webapp/,AVAILABLE}{C:\Users\Uwe
Schindler\Desktop\solr-9.3.0-slim\server/solr-webapp/webapp}
2023-07-27 08:48:23.929 DEBUG (qtp1963075870-46) [] o.e.j.s.h.ContextHandler
context=/solr||/techproducts/select @
o.e.j.w.WebAppContext@49a64d82{solr-jetty-context.xml,/solr,file:///C:/Users/Uwe%20Schindler/Desktop/solr-9.3.0-slim/server/solr-webapp/webapp/,AVAILABLE}{C:\Users\Uwe
Schindler\Desktop\solr-9.3.0-slim\server/solr-webapp/webapp}
2023-07-27 08:48:23.929 DEBUG (qtp1963075870-46) [] o.e.j.s.ServletHandler
servlet /solr|/techproducts/select|null|ServletPathMapping{matchValue=,
pattern=/, servletName=default, mappingMatch=DEFAULT,
servletPath=/techproducts/select, pathInfo=null} ->
default==org.eclipse.jetty.servlet.DefaultServlet@5c13d641{jsp=null,order=0,inst=true,async=false,src=DESCRIPTOR:file:///C:/Users/Uwe%20Schindler/Desktop/solr-9.3.0-slim/server/etc/webdefault.xml,STARTED}
2023-07-27 08:48:23.929 DEBUG (qtp1963075870-46) [] o.e.j.s.ServletHandler
chain=Chain@47a4b5d5(SolrRequestFilter==org.apache.solr.servlet.SolrDispatchFilter@30d15e4a{inst=true,async=false,src=DESCRIPTOR:file:///C:/Users/Uwe%20Schindler/Desktop/solr-9.3.0-slim/server/solr-webapp/webapp/WEB-INF/web.xml})->ChainEnd@2c16acde(default==org.eclipse.jetty.servlet.DefaultServlet@5c13d641{jsp=null,order=0,inst=true,async=false,src=DESCRIPTOR:file:///C:/Users/Uwe%20Schindler/Desktop/solr-9.3.0-slim/server/etc/webdefault.xml,STARTED})
2023-07-27 08:48:23.929 DEBUG (qtp1963075870-46) [] o.a.s.s.SolrDispatchFilter
Request to authenticate: org.apache.solr.servlet.ServletUtils$1@5726199e,
domain: 127.0.0.1, port: 8983
2023-07-27 08:48:23.929 DEBUG (qtp1963075870-46) [] o.a.s.s.SolrDispatchFilter
User principal: null
2023-07-27 08:48:23.929 DEBUG (qtp1963075870-46) [ x:techproducts]
o.a.s.s.AuthorizationUtils AuthorizationContext : userPrincipal: [null] type:
[READ], collections: [], Path: [/select] path : /select params :
2023-07-27 08:48:23.929 DEBUG (qtp1963075870-46) [ x:techproducts]
o.a.s.s.RuleBasedAuthorizationPluginBase Attempting to authorize request to
[/select] of type: [READ], associated with collections [[]]
2023-07-27 08:48:23.929 DEBUG (qtp1963075870-46) [ x:techproducts]
o.a.s.s.RuleBasedAuthorizationPluginBase Authorizing collection-aware request,
checking perms applicable to all (*) collections
2023-07-27 08:48:23.929 DEBUG (qtp1963075870-46) [ x:techproducts]
o.a.s.s.RuleBasedAuthorizationPluginBase Found perm [{
"name":"autoscaling-write",
"role":"admin",
"index":5}] to govern resource [/select]
2023-07-27 08:48:23.929 DEBUG (qtp1963075870-46) [ x:techproducts]
o.a.s.s.RuleBasedAuthorizationPluginBase Governing permission [{
"name":"autoscaling-write",
"role":"admin",
"index":5}] has role, but request principal cannot be identified; forbidding
access
2023-07-27 08:48:23.929 DEBUG (qtp1963075870-46) [ x:techproducts]
o.a.s.s.AuthorizationUtils USER_REQUIRED null null
2023-07-27 08:48:23.929 DEBUG (qtp1963075870-46) [ x:techproducts]
o.e.j.s.HttpChannelState sendError HttpChannelState@ca1dc41{s=HANDLING
rs=BLOCKING os=OPEN is=IDLE awp=false se=false i=true al=0}
{noformat}
The reason is that the role map still contains the *outdated* 8.x
"autoscaling-write" permission and for unknown reason it is selected as
permission that needs to be enforced for /select queries to the core. I have no
idea why this happens! This is in my opinion the main issue here. After that,
the rule based authorization figures out that the principal is null and send
the 401 response with useless error message (and by default no log entry at
all!!!!).
After removing the outdated role from the security.json, requests to /select go
through without authentication.
This problem may affect other people when upgrading Solr, as it is totally
unexpected that a no longer existing permission is selected to authorize!
To fix please try to be more helpful:
- Log warnings when authorization fail, so one must not use DEBUG logging!
- fix the bug that "autoscaling-write" is selected as permission for any
request to the core (not only /select is affected, everything).
- if a permission is unknown (legacy from 8.x), a warning should be printed on
startup and in the admin UI
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
