Details
-
Bug
-
Status: Closed
-
Major
-
Resolution: Fixed
-
9.0, 9.1, 9.2, 9.3, 9.4
-
None
Description
I had a very strange behaviour of Authorization after migrating a standalone solr instance to Solr 9 keeping the existing security.json file.
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/.... on cores/collections 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.
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}
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 perm 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
Attachments
Attachments
Issue Links
- links to
