[
https://issues.apache.org/jira/browse/SOLR-16907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Uwe Schindler updated SOLR-16907:
---------------------------------
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.
{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
was:
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
> 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.0, 9.1, 9.2, 9.3
> Reporter: Uwe Schindler
> Priority: Major
> Attachments: security.json
>
>
> 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.
> {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: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
